Где поставить такую ​​логику бизнеса? Сервис против ДАО?

Question

0:

1. Spring MVC - Hibernate.
2. Контроллер -> Сервис -> DAO
3. Теперь у меня есть метод, который извлекает что-то из БД и EVERYTIME, он делает это, должен сделать другой метод, сказать «processList» (что-то вроде изменения некоторых значений в списке в зависимости от на некоторых параметрах экрана).

Вопрос:

1. Какой слой нужно поместить этот "PROCESSLIST"? (Контроллер, Сервис или DAO? И почему)

Мне действительно нужны некоторые разъяснения j2ee сейчас, я знаю, что MVC одинакова на разных языках, но я просто должен быть уверен :) Если я делаю это в .net Я бы, несомненно, поставил это на службу.

Answer 1

Это действительно зависит от того, что делает processList. Золотого правила нет. Некоторые правила, которые я пытаюсь выполнить, следующие:

1. Никогда не делайте звонки между основными объектами на одном слое.
   • ManagementServiceImpl никогда не следует звонить NotificationServiceImpl.
2. Не устанавливайте круговые зависимости между объектами.
   • Это очень похоже на приведенное выше.
3. Если вы нашли себя повторять некоторую логику по нескольким основному объекту, попытайтесь перестроить код и распаковать его в специализированных логических классах (это улучшит блок-тестирование, а).
   • E.g. UserUpdateHandler или NotificationDispatcher (они до сих пор принадлежит уровню сервисов -> никто больше позволено называть их) ...
4. Поместите код, где он логически принадлежит.
   • Не отвлекайтесь на тот факт, что какой-то класс должен что-то сделать. Возможно, это не место для кода.
5. Никогда не пишите полностью обобщенный код, прежде чем понадобится.
   • Это имеет свой термин как преждевременное обобщение, что плохая практика похожа на преждевременной оптимизации. Сохранение нескольких строк кода теперь может привести к вытягиванию волос в будущем.
6. Всегда пишите код, который может быть обобщен.
   • Это не противоречит предыдущему. Это говорит - всегда пишите с обобщением в виду, однако не беспокойтесь писать, если это не нужно. Думайте заранее, но не обязательно действуйте заранее.
7. Оставить бизнес-логику для уровня обслуживания, логики сохранения данных на уровне данных и логики взаимодействия пользователя с уровнем представления.
   • Не пытайтесь разобрать пользовательский ввод в сервисном слое. Это не так, как подсчет конечной цены в приложении электронного магазина не относится к уровню представления.

---

Некоторые примеры processList:

• Пример I - извлечение дополнительных отношений через Hibernate#initialize
  • Это то, что действительно между слоем обслуживания и DAO , В старых проектах у нас был специализированный класс FetchHandler (принадлежащий служебному слою). В новых проектах мы полностью отдаем это DAO.
• Пример II - пройти через список и добавить деловому Validation сообщения в результате
  • сервисный слой, без сомнения
• Пример III - пройти через список и подготовить UI-сообщения на основе ошибок при проверке
  • уровень презентации

---

Примечание стороны:

• MVC это разные вещи из трехслойной архитектуры.
• M модель охватывает все три слоя. Уровень презентации включает в себя как V просмотров, так и C контроллеры.