MVC Mayhem;Разбираем модель ответственности и структуры

Question

Мое понимание архитектур типа MVC за последние несколько недель / месяцев значительно улучшилось (я бы сказал), и я в основном благодарен коллегам-энтузиастам SO; итак, спасибо!

Мне все еще что-то бросает вызов, Model. Пока я разобрался и создал;

• Простой Request объект, который объединяет данные запроса (GET / POST / и т. Д., HTTP-заголовки и т. Д.)
• Простой Response объект, который собирает данные ответов (HTML, JSON, HTTP заголовки и т. Д.)
• Причудливый Router, который разрешает URI в таблицу маршрутизации на основе регулярных выражений, проверяет их на основе Controller существования / наследования файла / класса и обновляет объект Request любыми дополнительными параметрами.
• Простой Dispatcher объект, который устанавливает рабочую среду, создает и инициализирует необходимый Controller и отправляет ему объект Request и Response для работы.

Теперь Model.

Я понимаю, что во многих (некоторых) обстоятельствах Model просто представляет связанную с ним сущность, таблицу, с методами CRUD (addUser(), deleteUser() и т. Д. ) В других Существуют и другие уровни абстракции, предотвращающие доступ контроллеров к более мелким функциям CRUD, методы консолидации (replaceUser() - удаляет, добавляет, затем возвращает пользовательские данные )

Мне интересно, каков мой лучший образ действий; по нескольким конкретным причинам.

Я создал класс Gateway, который действует как прокси для намеченного Model, выполняя проверки ACL ( с использованием объекта Acl, особый случай "Model" ) используя Request и требуемый метод и аргументы в качестве параметров для проверки. Controller отвечает за определение результата неудачной проверки ACL (отображать все, кроме этих данных, перенаправления и т. Д.)

Я также ввел ( и ранее упоминал его как гибридный REST / RPC, но я считаю, что это неверно, поскольку моя архитектура URI ресурса находится вне окна ) Уровень API RPC , Вызов API состоит из метода, аргументов и параметров запроса, управляется специальным ApiController и подается как обычный Model вызов Gateway.

Мне кажется, что лучший способ облегчить доступ к данным - это ( э-э ) один огромный объект модели, не обращая внимания на ORM, который поддерживает все методы взаимодействия с базой данных, доказывая простоту управления отношения Шлюз / ACL / Модель. Нет, это звучит неправильно.

Учитывая эти архитектурные решения, какой может быть мой лучший выбор для моделирования моего, хм .. Model? Действительно ли я бросил на ветер осторожность и лучшую практику с вышеупомянутыми вариантами дизайна?

Answer 1

Возможно, это просто семантика, но я бы сказал, что Модель - это представление данных, классов (и, следовательно, объектов), которые инкапсулируют сущности в вашем приложении. Есть еще одна недостающая часть, которую я назвал бы уровнем постоянства или доступа к данным (DAL). MVC как абстракция на самом деле не заботится о постоянстве, потому что на самом деле вам не нужно иметь постоянство, чтобы развиваться с использованием шаблона MVC. Во (почти?) Всех веб-приложениях, использующих MVC, у вас есть база данных, и поэтому вам необходим слой постоянства. Уровень персистентности понимает Модель и делает ее доступной для контроллера, но на самом деле это не часть модели.

Если вы отделяете концепции вставки / извлечения / обновления данных на уровне постоянства, у вас остаются контейнеры и связанная с ними логика ведения бизнеса / проверки, которая инкапсулирует представление сущностей ваших приложений. Они должны быть относительно небольшими, четко сфокусированными и взаимозависимыми только от фактических зависимостей данных между вашими сущностями. Эти небольшие модели, по одной на единицу, составляют Модель для вашего приложения. Ваш уровень персистентности (DAL / ORM) тоже не особенно велик, а скорее сосредоточен исключительно на взаимодействии с базой данных для получения / хранения моделей.