Как создать архитектуру слоя для веб-приложения?

Question

У меня проблема с дизайном при реализации 1 простого веб-приложения. Я использую web-контроллер struts2, IOC и Hibernate весны как упорный слой.

Потому что это веб-приложение очень просто при попрошайничестве. Поэтому у меня есть только 2 слоя: 1 слой DAO, который используется для доступа к базе данных. Почти каждая таблица имеет отношение к DAO. 2 Action layer. Пользовательские struts2. Я удовлетворен этой архитектурой, потому что может быстро реализовать мое веб-приложение. По мере того, как проект становится больше, я обнаружил, что уровень действия становится большим и сложным, и его очень трудно использовать повторно. Я пытаюсь создать сервисный уровень, для решения сложной бизнес-логики это хорошо, но в моем приложении все еще много логики. Например: Загрузите 1 объект, сохраните 1 объект и получите сбор с помощью некоторого условия и покажите его на веб-странице. Если каждый простой метод доступа к БД имеет соответствующий метод обслуживания. Все еще стоило больших усилий. Как решить эту проблему? И я думаю, что если сервисный уровень существующий, прямой вызов DAO-уровня еще не очень хорош для моего приложения. Является ли какое-либо хорошее решение для такого небольшого веб-приложения?

Answer 1

При планировании различных слоев в веб-приложении хорошей практикой является явная защита атрибутов и ассоциаций в вашей модели от манипулирования без предоставления контекста идентификации.

Это то, что не должно выполняться ни в слое DAO, ни в контроллере. Вы должны обернуть свой слой DAO на уровне обслуживания и попросить диспетчера напрямую обратиться к службам, а не к DAO.

Защита вашей модели от нежелательных манипуляций означает, что вы, например, настраиваете количество информации, передаваемой в структуре данных между контроллером и службой, на фактическую операцию, которую вы хотите выполнить.

Например: добавление или удаление элемента из коллекции является явной операцией в службе, это не происходит неявно, манипулируя коллекцией как членом объекта DAO и передавая этот DAO обратно в службу.

Вместо ваш сервис может выглядеть следующим образом:

+ getAllCompanies(): CompanyType[*] 
+ getAllEmployeesOfCompany(c: CompanyType) : EmployeeType[*] 
+ addEmployeeToCompany(e: EmployeeType, c: CompanyType) 
+ removeEmployeeFromCompany(e: EmployeeType, c: CompanyType) 

Дополнительное преимущество такой архитектуры является то, что уровень службы служит границей для ваших сделок. Использование методов вашего контроллера в качестве границы для ваших транзакций на самом деле является очень плохой привычкой. Вы даже можете назвать это анти-шаблоном. Зачем? Потому что, например, это будет означать, что когда ваш клиент зависает, он откатит вашу транзакцию. Это явно нежелательно в 99% случаев.

Answer 2

Как @mwhs прокомментировал, Apache Isis предоставляет множество рекомендаций по планированию вашего приложения. Чтобы выяснить, соответствует ли это вашим требованиям, вы можете пройти через этот tutorial, который я представил на недавней конференции.