DAO & Business Logic [closed]

Question

I was wondering about the amount of business logic that a DAO should deal with.

Ok, we all know that the purpose of DAOs is to encapsulate data access and hide all the informations about it as well as the implementation. Furthermore, the goal of DAOs is also to separate business logic from data access logic.

I would argue that a DAO must have some business logic in it, e.g. what if a business object could not be deleted or updated due to some requirements of the specific domain? I guess that no one would implement the delete/update method for that DAO, and -for as I see it- this implies some knowledge of business logic.

Now, as you can imagine my question is more conceptual than practical, so it's useless advice to use an ORM as there is no concrete scenario of use.

The question is: how much business logic a DAO should handle, given any restriction on the manipulation of persistent data?

Example:
BusinessObject1 can be updated only once in its lifetime. Supposed that we can easily know if it has already been updated, should the DAO throw an exception if we try to update BusinessObject1 again? Or it should detect nothing and this should be managed in the business layer?

Answer 1

If you store your data in a database that has referential integrity rules, then your data layer has business rules in it.

This is the problem with all rules of thumb. They work until they don't. The point is not to avoid rules in your data layer, the point is to only put rules in the data layer that belong there. For example, rules which enforce the validity of stored data belong in the data layer. Rules that enforce how data is used don't belong in the data layer.