Приложение MVC. Как вписывается многоуровневая архитектура?

Question

Я новичок в концепции MVC и многоуровневой веб-архитектуры. Я разрабатываю приложение PHP и использую одну из доступных фреймворков MVC. Мой вопрос заключается в следующем:

Из того, что я понимаю, MVC сам по себе не считается многоуровневой архитектурой. Я могу понять, как использование только MVC-это шаг вперед от неструктурированного подхода, но я размышлял о том, как будет соответствовать простой 3-уровневой архитектуре? Будет ли MVC проживаться в презентационном слое? Каковы достоинства добавления многоуровневого подхода? Из того, что я собираю, только с MVC нет явных объектов данных, ответственных за извлечение данных из базы данных, и это обычно вбивается в модель. Аналогичным образом, бизнес-логика, которая в трехуровневой архитектуре будет находиться в «бизнес-сложном» (или как вы хотите ее назвать), может быть вовлечена в контроллер.

Мое понимание несколько правильно? Я знаю, что задал много вопросов, но я хотел бы услышать, как вы обсуждаете, как вы включили архитектуру N-уровня в свою структуру MVC (PHP или иное), поскольку я предполагаю, что эти два не являются взаимоисключающими. Спасибо!

Answer 1

М) м - твоя модель. Как правило, это живет в вашем бизнес -слое или слое прямо за ваш презентационный уровень. Многим людям не нравится, что уровень презентации имеет какие -либо знания о бизнес -уровне, и поэтому они еще больше абстрагируют, что, имея то, что называется ViewModel. Это часто представляют собой DTO (объекты передачи данных), которые свободно сопоставляют в вашей модели домена. Для меня (.net Guy) есть такие инструменты, как Automapper, чтобы сделать преобразование из модели домена, чтобы просмотреть модель.

V) V - это ваше мнение. Вид - ваш презентационный слой. Это фактический код HTML или PHP, с которым пользователь напрямую касается и взаимодействует. Представление должно быть максимально легким (это означает отсутствие логики, если это возможно). Постарайтесь сохранить какие -либо виды сценариев, а затем введите сценарии из вида и придерживайтесь просто отображения и сбора данных. Представьте ViewModel своим веб -дизайнерам, чтобы они не загрязняли ваш DomainModel.

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

Где поступают многоуровневые концепции дизайна, находятся за уровнем презентации (где в первую очередь находится MVC). Когда контроллер получает данные из представления и передает их обратно на задний план (если вы следуете за DDD или Domain-управляемым дизайном) передаст данные в службу приложения (класс, который координирует задний конец, имеет значение). Служба может дополнительно подтолкнуть данные в уровень репозитория (который является классом, который говорит с базой данных, файловой системой, веб -сервисами и т. Д. - любые инфраструктурные материалы). DDD-большая тема, но вы получите голову вокруг подхода N-уровня и то, как он работает с MVC.

При исследовании этой темы взгляните на МОК (инверсия контроля), DI (инъекция зависимостей), TDD (разработка на основе теста) и как можно больше моделей (фасад, фабрика и т. Д.).

Answer 2

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