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

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

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

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


architecture model-view-controller multi-tier
person oym    schedule 16.07.2009    source источник
comment
Возможные дубликаты: stackoverflow.com/questions/899803/, stackoverflow.com/questions/2843311 /, stackoverflow.com/questions/14451444 /   -  person pgpb.padilla    schedule 13.08.2013

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

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

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

person Andrew Siemer    schedule 16.07.2009

arrow_upward
-1
arrow_downward

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

person Beep beep    schedule 16.07.2009