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

Question

Я думаю о наилучшем подходе к разделению представления модели и контроллера - для Java и использованию Eclipse, если это имеет какое-либо значение.

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

• com.company.client (контроллер)
• com.company.client.model

• com.company.client.view

• com.company.another (контроллер)

• com.company.another.model

• com.company.another.view

• com.company.yetAnother (контроллер)

• com.company.yetAnother.model
• com.company.yetAnother.view

(предположим, много разных пакетов, каждый со своим видом и моделью)

Я думал об использовании:

• com.company.client
• com.company.another

• com.company.yetAnother

• com.company.model.client

• com.company.model.yetAnother

• com.company.view.client

• com.company.view.another
• com.company.view.yetAnother

Я даже думал о размещении контроллера, модели и вида в разных проектах. Может быть, это было бы еще более модульно, и я был бы более уверен, что представление не использует контроллер, например (поскольку проект контроллера будет включать представление, но не наоборот).

Так каков наилучший подход к разделению M, V и C?

(рассмотрим веб- и настольные приложения, а не только веб)

Answer 1

Квест Graal! У вас есть двумерная матрица с вертикальным (MVC) и горизонтальным (бизнес-правилами) слоями ...

• Я не нашел строгого ответа
• Ваш первый подход выглядит хорошо, потому что модульный ориентированный (может быть непреднамеренный)
• Для небольшого приложения ваш второй, хотя, возможно, приемлемый

Для меня ответом является слово: Зависимости
Продолжайте искать в «дизайне / стратегии упаковки»; "Зернистость"

Некоторое чтение

• http://techdistrict.kirkk.com/2009/08/05/modularity-patterns/
• http://techdistrict.kirkk.com/2010/04/22/granularity-architectures-nemesis/

Я настоятельно рекомендую это:

• http://www.jgoodies.com/articles/patterns-and-binding-old.pdf

УДАЧИ!

Answer 2

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

• наименование
• модульность

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

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

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

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

com.mycompany.app.web

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

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

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

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

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

Другая распространенная ошибка - путать Controller с Business Logic ;бизнес-логика должна быть размещена в модуле и распределена между модулями представления, контроллером в пространстве имен модуля представления (веб-интерфейс или рабочий стол).

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

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

Answer 3

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

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

Answer 4

Вот пример использования многоуровневой архитектуры с тремя слоями ( приложение, домен, пользовательский интерфейс ):

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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