Where to put such business logic? Service vs DAO?

Question

Considering:

• Spring MVC - sleep mode.
• Controller → Service → DAO
• Now I have a method that extracts something from the database and EVERYTIME, it does it, another method should do it: "processList" (something like changing some values ​​in the list depending on some screen parameters).

Question:

• What layer do I put in this "processList"? (Controller, service or DAO? And why)

I really need some clarification of j2ee now, I know that MVC is the same in different languages, but I just have to be sure :) If I do this in .net, I would certainly put this at the service.

Answer 1

It really depends on what processList does. There is no golden rule. Some of the rules I'm trying to follow are as follows:

• Do not make calls between core objects at the same level.
  • ManagementServiceImpl should never be called NotificationServiceImpl .
• Do not create circular dependencies between objects.
  • This is very similar to the one above.
• If you find that you are repeating some logic over several basic objects, try rebuilding the code and extracting it in specialized logical classes (this will also improve unit testing).
  • eg. UserUpdateHandler or NotificationDispatcher (they still belong to the service level -> nobody can call them) ...
• Put the code into which it logically enters.
  • Do not be distracted by the fact that some class must do something. This may not be the right place for the code.
• Never write fully generalized code before you need it.
  • It has a term like premature generalization, which is bad practice, similar to premature optimization. Saving multiple lines of code can now lead to hair stretching in the future.
• Always write code that can become generalized.
  • This does not contradict the previous one. It says - always write with a generalization in mind, however do not worry to write if it is not necessary. Think in advance, but don't necessarily act in advance.
• Leave the business logic for the service level, data retention logic for the data level, and the user interaction logic with the presentation level.
  • Do not try to parse user input at the service level. This is not the case as the calculation of the final price in the electronic store application does not apply to the level of presentation.

---

Some examples for processList :

• Example I - Choosing Additional Relationships via Hibernate#initialize
  • This is what really lies between the service and the DAO layer. In older projects, we had a specialized class FetchHandler (belonging to the service layer). In new projects, we fully surrender this to the DAO.
• Example II - view the list and add the business confirmation message to the result
  • level of service no doubt
• Example III - View the list and prepare user interface messages based on validation errors
  • presentation level

---

Side note:

• MVC differs from three-layer architecture.
• Model M covers all three layers. The presentation level includes both V and C tags.