Контроллер принадлежит к слою презентации?

Ответ 1

Уровень представления содержит представления и. Вы не должны допускать архитектуру MVC для архитектуры многоуровневого уровня (особенно трехуровневую архитектуру). В большинстве случаев Model/View/Controller не является основным дизайном веб-приложения, это всего лишь подмножество архитектуры многоуровневого уровня.

Взгляните на эту упрощенную схему (у вас могут быть DAO в выделенном уровне доступа к данным, но это не важно в этом сообщении):

Spring MVC представляет собой инфраструктуру представления: он имеет дело с контроллерами и представлениями. Но почему "М" в Spring MVC? Просто потому, что, как и многие другие рамки представления, он, естественно, имеет дело с представлением модели/сущности ( "M" ). Это представление используется в ваших контроллерах, отображается в ваших представлениях, представлено в ваших формах и т.д. . Поэтому структура называется Spring MVC, даже если модель/сущность не является частью уровня предварительной оценки.

Я думаю, что это хорошее имя для этой Framework, потому что это действительно "MVC". Действительно, представление модели/объекта может быть:

• direct: структура напрямую обрабатывает объект model/entity
• косвенный: структура обрабатывает объект формы или DTO, который содержит информацию, связанную с одним или несколькими объектами.

Spring рекомендация заключается в непосредственном использовании объекта model/entity ( "M" ):

Многоразовый бизнес-код, без необходимости дублирования. Использовать существующие бизнес-объекты как объекты команд или форм вместо их зеркалирования для расширения определенного базового класса базы данных.

Вот почему я говорю, что структура очень ориентирована на "MVC", по сравнению с другими, такими как Struts, где вам нужно использовать разные объекты формы.

Некоторые интересные ссылки:

• Сравнение между архитектурой Multitier и MVC, из Википедии
• Это сообщение в блоге о трехуровневой архитектуре в ASP.NET
• Это изображение блога трехуровневой архитектуры
• глава DispatcherServlet из Spring документации

Ответ 2

Контроллер управляет логикой уровня представления. Для всего бизнес-кода, случаев использования транзакций, сохранения и т.д. Он обычно делегирует сервисный уровень.

Типичным способом выполнения этого является внедрение транзакционных сервисов как spring beans и встраивание этих spring beans в контроллеры. Типичный пример использования: createa new product:

• Контроллер получает команду bean из браузера
• Он подтверждает, что все необходимые данные присутствуют, а если нет, повторно отображается страница создания продукта с сообщениями об ошибках
• Он вызывает службу bean для создания продукта
• Служба bean выполняется в транзакции. Он получает категорию продукта из базы данных, присоединяет продукт к своей категории, вычисляет цену продукта на основе текущих стратегий ценообразования, отправляет JMS-сообщение во внешнее приложение и возвращает идентификатор созданного продукта.
• Контроллер перенаправляет на страницу сведений о продукте, используя идентификатор созданного продукта в качестве параметра URL.

Ответ 3

В значительной степени зависит от того, какой вкус MVC вы используете, и в какой среде вы его используете.

Например, ASP.NET MVC полностью является шаблоном пользовательского интерфейса, поэтому все три части являются частью презентации.

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

Единственная универсальная истина заключается в том, что вы не должны делать бизнес-логику в контроллере, если не можете помочь. Там, где существует бизнес-логика, зависит от многих факторов. Это может быть частью модели в некоторых реализациях, или это может быть отдельный слой за пределами MVC