Я реализовал то, что, по моему мнению, было довольно приличным представлением MVC в нескольких веб-приложениях, но, поскольку я присоединился к crackoverflow, я обнаружил, что, возможно, мои первоначальные определения были немного упрощенными, и поэтому мне действительно хотелось бы получить некоторые разъяснения относительно различий между Уровень доступа к данным и модель или уровень домена веб-приложения.
В контексте я в настоящее время использую объекты доступа к данным, которые реализуют функции CRUD для одной записи в таблице, которую представляет объект, а также функцию get (), которая возвращает объект, который позволяет мне выполнять итерацию по всем объектам, критерии для функции get ().
Эти объекты доступа к данным ссылаются непосредственно из сценариев контроллера, которые содержат мою бизнес-логику.
Если это имеет значение, я работаю в PHP и MySQL, но меня интересуют предложения, которые могут быть закодированы на других языках.
UPDATE: для более конкретного примера у меня есть таблица, называемая пользователем (соглашение здесь – это уникальные имена таблиц), которая содержит такую информацию, как адрес электронной почты, активное состояние, имя пользователя, пароль, к какой компании они принадлежат и т. Д. Этот базовый объект выглядят следующим образом:
class User implements DataAccessObject { protected $user_id; protected $email; protected $username; protected $password; protected $company_id; protected $active // Bool that holds either a 0 or 1 public function __construct ( $user_id ) // Uses Primary Key to know which record to construct { $sql = //Sql to get this information from the database. // Code necessary to assign member variables their values from the query. } public function insert(){} public function update(){} public function delete(){} public static function get($filters, $orderVals, $limit){} // An object such as user might also contain the following function definition public static function login($username, $password){} } Похоже, что я мог убрать уровень DAO Layer и Model в упрощенную форму, которая сочетает в себе функции любого типа реального мира (такие как логин для пользователя) с функциями доступа к данным.
Модельные классы автономны как хорошая, чистая, высокоточная модель реальных объектов. Если это бизнес-домен, это могут быть клиенты, планы, продукты, платежи, все такое. Ваше приложение работает с этими классами. Идея заключается в том, что ваше приложение является моделью обработки объектов домена в реальном мире. Ваше приложение может иметь функции метода, которые выглядят как глаголы, которые люди действительно делают, а реализация этих функций методов выглядит как реальное описание объектов реального мира.
Важно: это (идеально) независимо от большинства технических соображений. Это самая чистая модель объектов домена, которую вы можете определить. [Да, у вас есть проблемы с внешним ключом, и да, вам нужно сделать ваши объекты модели осведомленными о некоторых компонентах доступа к данным, чтобы объект модели мог находить друг друга, заданные только внешние ключи, а не фактический объект. Хороший уровень ORM обрабатывает эту проблему навигации для вас.]
Модель, полная SQL, не является хорошей моделью. Реальный мир также не заполнен SQL. Счет-фактура – это документ с именами и адресами, а также дата доставки и куча таких вещей.
Классы доступа обрабатывают постоянное хранилище. Обычно это включает отображение ваших объектов модели в таблицы реляционной базы данных. SQL-ориентированный уровень доступа к данным восстановит вашу модель из реляционной базы данных и сохранит вашу модель в реляционной базе данных. Уровень доступа к данным YAML будет считывать и записывать файлы YAML из вашей модели.
Иногда шаблон проектирования объектно-реляционного сопоставления (ORM) используется для обеспечения четкого разделения между миром SQL и вашей моделью. Иногда объект доступа к данным (DAO) обрабатывает это разделение между SQL и моделью. Объект ORM или DAO может быть заполнен SQL.
Действительно, когда вы меняете продукты базы данных, единственное изменение происходит в DAO или ORM. Модель никогда не меняется, поскольку она не зависит от SQL, YAML, JSON, XML или некоторых других методов сериализации.
Если ваш DAO создает и сохраняет объекты модели, я думаю, что у вас есть части модели MVC, которые были реализованы достаточно хорошо. Вы можете посмотреть пакеты ORM, чтобы получить дополнительные идеи о состоянии дел. Я сам поклонник iBatis .
Но это всего лишь 1/3 всего мирового взгляда MVC. И, конечно же, пуристы скажут вам, что MVC – это только рабочий стол или только небольшой контент или отличается от обычной веб-реализации MVC.
Это всего лишь вопрос более высокой абстракции. Если вы думаете о какой-либо проблеме бизнеса, которую вы собираетесь решить, вы хотите думать об этом с точки зрения понятий (сущностей, отношений, процессов и т. Д.) Этого бизнеса, а не в терминах объектов базы данных или на более подробном уровне, в термины внутренних компонентов некоторой конкретной системы баз данных (например, MySQL). Таким образом, вы можете самостоятельно смоделировать домен (т. Е. Бизнес и его правила) независимо от конкретной технологии, которую вы используете для реализации.
Другими словами, когда вы говорите «уровень доступа к данным», вы говорите о таблицах, строках, типах данных или даже о подходах к доступу к этим данным (например, с помощью Active record pattern), когда вы говорите о домене, вы говорить о бизнес-объектах, бизнес-правилах и бизнес-процессах.
И, кстати, при использовании шаблона MVC вы должны инкапсулировать бизнес-логику на уровне вашей модели (домена) (как я сказал выше), а не в контроллерах – они должны просто запускать эти правила, так сказать.