DAO and business logic

Question

I wondered about the amount of business logic that the DAO needs to deal with.

Well, we all know that the goal of the DAO is to encapsulate data access and hide all information about it, as well as implementation. In addition, the goal of the DAO is also to separate business logic from data access logic.

I would say that DAO should have some kind of business logic, for example. What if a business object cannot be deleted or updated due to some requirements of a particular domain? I assume that no one will implement the delete / update method for this DAO, and 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 ORM, since there is no specific use case.

The question is, how much business logic should the DAO process, given any constraint on persistent data processing?

Example:
BusinessObject1 can only be updated once in a lifetime. Suppose we can easily find out if it is updated if the DAO throws an exception, if we try to update BusinessObject1 again? Or should it not detect anything, and should it be managed at the business level?

Answer 1

If you store your data in a database with referential integrity rules, then there are business rules at your data level.

This is a problem with all rules of thumb. They work until they do it. It's not about not breaking the rules at your data level, but about placing the rules only in the data layer. For example, rules that enforce the validity of stored data apply to the data layer. Rules that ensure the use of data do not apply to the data layer.

Answer 2

You can define the restrictions in BusinessObject1 (for example: you can only update 1 time) that your DAO will read. Then, when you give the DAO a modified object and tell it to keep this modification (update), the DAO will throw an exception.

I think this is how Doctrine (ORM Data Mapper) works.

Answer 3

Your concern is to

What if a business object cannot be deleted or updated due to some requirement of a specific domain?

I think its still a good idea to keep the business logic separate from the DAO, because its a business that continues to change most of the time. Therefore, if your requirement is to apply a business constraint when performing the update n delete, then the service level should check this constraint. This way you do not have to make changes to the DAO layer.

In addition, if in the future you want to switch to another database, you also do not have to worry about business logic, since you need to focus only on specific db operations.

Answer 4

If your application is divided into components that are independent of each other, you end up with a business component, a database component (possibly implemented as a DAO), and a user interface component. The business logic component is responsible for enforcing the basic business rules for the application; a database component for accessing data and enforcing data manipulation rules; and finally, a user interface component for managing user interaction.

With this design, there is no argument about whether the database component should contain logic: of course, it should be. He needs rules to control the storage, retrieval and interpretation of data. However, the type of logic it contains is different from business logic or user interface logic. And, as already indicated, the database component should not be a software component; it may consist of stored procedures, functions, and triggers in your database.

In essence, feel free to introduce logic into the DAO, but make sure that this logic only applies to operations that are related to data access. Likewise, it is good to have logic in the user interface component to control user interaction.