Лучший подход к разделению модели, представления и контроллера

предполагая, что вам приходится иметь дело с нетривиальным проектом, я думаю, что ваша проблема имеет два аспекта, которые необходимо совместно рассмотреть для настройки архитектуры и качества кода:

• наименования
• код

для именования я стараюсь иметь самую высокую когезию в каждом пространстве имен и следовать Общий Принцип Закрытия и Общий Принцип Повторного Использования.

для модульности я пытаюсь использовать модуль для каждый архитектурный главный вопрос проекта и удобно назвать его пакеты.

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

В моей Java IDE (например, Eclipse) я использую проект для каждого модуля, поэтому веб-модуль будет проектом, а настольный модуль-другим проектом. В веб-проекте, например, у меня есть общий префикс, такой как as:

com.mycompany.app.web

и в нем у меня есть .контроллеры (или действия) потомок, a .модели потомок и так далее.

com.mycompany.app.web.models
com.mycompany.app.web.actions

Если я использую базу данных, я полагаюсь на модуль DAO, другой проект. Модуль DAO не имеет презентации, поэтому у него нет подхода MVC. Он сохраняет объекты домена, поэтому, возможно, он полагается на модуль домена. В этих модулях я использую следующие префиксы:

com.mycompany.app.domain
com.mycompany.app.dao

Я стараюсь не путать модель в MVC с приложением домен; они не одно и то же.

еще одна распространенная ошибка-путать контроллер С Бизнес-Логики; бизнес-логика должна быть помещена в модуль и презентации модулей, контроллера в пространстве имен модуля презентации (Web или desktop).

A модель (в MVC, модель представления) - это объект, используемый представлением, чтобы показать что-то для пользователя: он может содержать один, комбинацию или коллекцию домен объекты. The контроллер использует доступные модули (DAO и т. д.) построить вид модель и затем передает его в посмотреть.

посмотреть тогда можно положиться только на ее модель (только один, явно созданный контроллером) и запрашивать модели только для контроллеров (единственный способный создавать модели). посмотреть, особенно для веб-презентаций, часто кодируется на смеси языков, поэтому часть кода может оставаться вне соглашений об именах.

вы только обеспокоены "разделением" модели, представления и контроллера в том, что касается именования и пакетов? Кажется, это все, о чем вы спрашиваете.

я склонен выкладывать свои пакеты как таковые:

• com.company.app.domain - классы модели домена для приложения, просто Java beans (только геттеры и сеттеры, очень мало, если есть какая-либо логика). Это используется как "модель" во всем приложении и используется каждым слоем моего приложения.
• com.company.app.service - Классы уровня обслуживания приложения, содержащие бизнес-логику.
• com.company.app.web.controllers - классы контроллеров для моего webapp. Другие веб-классы помещаются в различные другие подпакеты web.
• com.company.app.dao - интерфейсы DAO для доступа к классам модели домена-т. е. для извлечения пользователя из базы данных и т. д.

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

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

большинство приложений, над которыми я работаю, следуют следующей структуре упаковки: *.домен.* ,услуга.subservice, *.Дао.* ,сеть.контроллеры. Это хорошо работает для отслеживания циклических зависимостей в базе кода и / или зависимости, которые текут неправильным образом ( контроллер попадает в dao без косвенного обслуживания ). Оно также обеспечивает очень просто упаковывая структуру которая полезна и non обременительна.

однако это ломается при просмотре автоматизированных оценок влияния зависимостей. В настоящее время я использую DependencyFinder с немного пользовательского кода для сравнения двух файлов jar перед QA. DependencyFinder вытащит все измененные методы и связанные с ними зависимости первого уровня. Пользовательский код должен пнуть, чтобы сопоставить измененные методы / классы с бизнес-функциями и выплевывает файл грамматики graphviz для рендеринга набора изменений на основе бизнес-функций, графика зависимостей для QA. В настоящее время мы пытаемся использовать результаты инструмента для планирования интеллектуального регрессионного теста, особенно для производственных дефектов, которые переходят на производство без полного многонедельного регрессионного теста.

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

пример использования Многоуровневая Архитектура дизайн с тремя слоями (применение, домен, ui):

в model-view-controller (MVC) модель будет находиться в нижнем слое, например com.company.myapp.domain. Все остальные слои могут получить доступ к модели. Тогда представление и контроллер будут в com.company.myapp.ui. Это означает Controller класс всегда находится в том же слое, что и View. Не путайте MVC-Controller с другими классами контроллеров, которые предоставляют логика приложения и находятся на уровне приложения. Например,SalesController на com.company.myapp.application, который обеспечивает системные операции для обработки продаж.

теперь вы можете себе представить SalesController изменяет некоторые данные в вашей модели (обновляет продажу), и модель затем сообщает MVC-Controller, который обновляет представление.

Примечание: все модели находятся в domain слой. Все представления и контроллеры MVC находятся в ui слой. Контроллеры бизнес-логики находятся в application слой. Вы можете конечно, разделить эти три слоя, если у вас есть много классов с различными проблемами.

надеюсь, это поможет.

подумайте о том, как вы развиваетесь. Вы разрабатываете контроллер / Модель/Вид? Или вы разрабатываете по модулю. Скорее всего, вы развиваетесь на модуле, а не на слое MVC. Поэтому я думаю, что в этом и заключается ваш ответ. Попытайтесь сохранить имена пакетов как можно ближе к модулям, которые представляет ваша система (что вы уже делаете, я полагаю). Нет необходимости показывать Вам архитектурные варианты в именах пакетов.

отображение имен модулей и проблем с доменом в пакете создайте обслуживаемый и последовательного кода.