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

Question

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

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

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

Answer 1

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

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

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

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

При исследовании этой темы обратите внимание на IoC (инверсия управления), DI (внедрение зависимостей), TDD (разработка через тестирование) и как можно больше шаблонов (фасад, фабрика и т. Д.).

Answer 2

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