Лучше всего приблизьтесь для разделения Модели, Представления и Контроллера

Question

Лучше всего приблизьтесь для разделения Модели, Представления и Контроллера

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

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

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

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

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

Таким образом, что лучший подход должен разделить M, V, и C?

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

9

java model-view-controller architecture data-structures

задан 6 revs, 2 users 96% 11 December 2014 в 04:49

2 ответа

Другие вопросы по тегам:

java model-view-controller architecture data-structures

Похожие вопросы:

score 1 · Answer 1

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

Я стараюсь излагать свои пакеты следующим образом:

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

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

score 1 · Answer 2

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

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

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

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