Я уже некоторое время использую Struts и обычно добавляю весь бизнес-код в сам класс действий. Теперь кто-то сказал мне, что это плохая практика
Да, это так.
и я должен использовать шаблон фасада и бизнес-делегата.
Я не знаю об этом, может быть, да, может, нет, это зависит от вашей заявки. Попросите этого человека подробно рассказать, что он / она имел в виду.
Фасад используется на стороне бизнеса для обеспечения более простого интерфейса доступа к сложной системе (более сложный объект, набор объектов, другие внутренние системы и т. Д.), Скрывая сложность и взаимодействие этой системы от клиента системы. .
Бизнес-делегат используется на стороне представления, чтобы снова скрыть сложность бизнес-компонентов, вызываемых клиентом (управление поиском бизнес-компонентов с помощью Service Locator , управление сетевыми вызовами, исключениями и т. Д. ).
Таким образом, Фасад и Бизнес-делегат идут рука об руку, чтобы более свободно связать клиента с бизнес-услугами, которые он использует.
Теперь, если вы считаете, что Struts является приложением типа MVC , я не очень понимаю, как Facade и Business Delegate сочетаются друг с другом. Вот почему вы должны попросить человека подробно.
В Struts у вас есть:
- Модель, отвечающая за доменную логику
- a Представление, которое отвечает за представление состояния модели пользователю и позволяет взаимодействовать с пользователем;
- Контроллер, который действует как связующее звено между Моделью и Представлением, преобразуя пользовательские запросы в действия, которые должны быть выполнены Моделью, и после слов выбирает следующий Вид для отображения нового состояния Модели.
Вся логика домена должна быть в Модели. Ваш класс Action не является частью Model , он является частью Controller. Видите эти HttpServletRequest и HttpServletResponse объекты в методе execute ? Это похоже на предметную логику? Нет!
Вы не помещаете все свои бизнес-правила в класс Action. В классе Action вы делегируете классам, которые занимаются логикой домена. Обычно это происходит на уровне обслуживания .
Сервисный уровень связывается с внешним миром с помощью DTO с (обычно POJO с) и не заботится о типе своих вызывающих абонентов (веб-приложения HTTP, настольные приложения и т. Д.). Класс Action должен преобразовать параметры HttpServletRequest в соответствующий тип, ожидаемый уровнем обслуживания, и предоставить ему полный контроль. Когда MOdel возвращается, он отправляет результат в View.
Это хорошая практика, потому что теперь вы можете повторно использовать свой сервисный уровень и доменную логику, которую он содержит , он больше не привязан к какой-либо веб-среде (а именно Struts).
P.S. Одно слово совета. Не используйте объекты ActionForm в качестве DTO для сервисного уровня. Люди считают, что ActionForms принадлежат модели, но это не так. Формы действий - это паршивые овцы Struts, они не POJO, а слабо связаны со Struts, поскольку вам нужно расширить класс Struts ActionForm , чтобы они работали, а это означает тесную связь с каркасом.