Будучи довольно незнакомым с шаблонами проектирования и архитектурой, я с трудом объясняю другим, как именно разрабатывается мое последнее приложение. Я переключился с мысли, что это чистый n-ярус, чистый MVC и n-ярусный с MVC на уровне представления. В настоящее время я думаю, что последнее является правильным, но я хочу мысли от более опытных разработчиков.
Как это работает:
- Браузер отправляет HTTP-запрос Tomcat. Сопоставляет запрос через web.xml с сервлетом (который я называю контроллером)
- Контроллер создает один или несколько бизнес-объектов и вызывает для них методы, т. Е.
customerBO.getById(12), которые снова выполняют бизнес-логику / проверку перед вызовом одного или нескольких методов DAO, т. Е. customerDAO.getById(12). BO возвращает список CustomerVO в контроллер
- Контроллер подготавливает атрибуты для представления (JSP) (
request.setAttribute("customers", customers);) и выбирает для использования файл .jsp, который, в свою очередь, выполняет итерацию списка и возвращает XHTML обратно в браузер.
Структура (мое предложение / понимание)
Уровень представления : в настоящее время используется то, что я считаю веб-реализацией MVC: сервлеты (контроллеры), jsp (представления) и моя собственная реализация форм OO XHTML (т. Е. CustomerForm). Должна быть возможность использовать Swing / JavaFX / Flex GUI, отключив этот уровень представления без необходимости что-либо менять на уровнях ниже.
Уровень логики : разделен на два слоя с бизнес-объектами (BO) сверху. Отвечает за бизнес-логику, но я не нашел здесь много чего, кроме проверки ввода, поскольку приложение в основном состоит из простых действий CRUD ... Во многих случаях методы просто вызывают метод с тем же именем на уровне DAO.
Классы DAO с методами CRUD, которые снова связываются с уровнем данных ниже. Также есть методы convertToVO (ResultSet res), которые выполняют ORM из базы данных и (списки) объектов значений. Все методы принимают в качестве входных данных объекты-значения, т. Е. CustomerDAO-> save (voter) и возвращают обновленного избирателя при успехе и ноль при ошибке.
Уровень данных : В нижней части данные хранятся в базе данных или в виде файлов XML. Здесь я ничего не «кодировал», кроме некоторых хранимых процедур и триггеров MySQL.
Вопросы (кроме одного в названии):
- М в MVC. Я не уверен, смогу ли я назвать этот n-уровневый MVC, когда модели представляют собой списки / VO, возвращаемые из бизнес-объектов на логическом уровне? Должны ли модели находиться на уровне представления, когда здесь находится контроллер / представление? И можно ли шаблоны форм на уровне представления называть моделями? Если так; Можно ли рассматривать формы и списки из BO как M в MVC?
- Насколько я понимаю, в MVC представление должно наблюдать за моделью и обновляться при изменении, но это невозможно в веб-приложении, где представление представляет собой визуализированную страницу XHTML? Это, в свою очередь, приводит меня к вопросу: по-разному ли реализован MVC для веб-приложений и обычных настольных приложений?
- Я не использую шаблон Front Controller, когда все HTTP-запросы явно отображаются в web.xml, верно? Чтобы использовать Front Controller, мне нужно перенаправить все запросы на стандартный сервлет / контроллер, который, в свою очередь, оценивает запрос и вызывает другой контроллер?
- Бизнес-уровень показался мне немного "бесполезным" в моем приложении. Что вы обычно кладете в этот слой / объекты? Всегда ли нужно иметь бизнес-слой? Я знаю, что она должна содержать «бизнес-логику», но что это такое? Я просто выполняю проверку ввода и создаю экземпляр одного или нескольких DAO и вызываю для них соответствующие методы ...
Я понимаю, что есть MVC-фреймворки, такие как Struts для Java, но с тех пор, как это было мое первое веб-приложение на Java, я попытался глубже понять, как все работает. Оглядываясь назад, я надеюсь, что вы сможете ответить на некоторые вопросы, на которые я наткнулся.