Разница между уровнем доступа к данным и моделью в MVC
Я реализовал то, что, по моему мнению, было довольно приличным представлением MVC в нескольких веб-приложениях, но с тех пор, как я присоединился к crackoverflow, я обнаружил, что, возможно, мои первоначальные определения были немного упрощенными, и поэтому я действительно хотел бы получить некоторые разъяснения о различиях между уровнем доступа к данным и уровнем модели или домена веб-приложения.
Для контекста в настоящее время я использую объекты доступа к данным, которые реализуют функции CRUD для одной записи в таблице что объект представляет, а также функцию get(), которая возвращает объект, позволяющий мне перебирать все объекты, соответствующие критериям для функции get().
На эти объекты доступа к данным ссылаются непосредственно из сценариев контроллера, которые содержат мою бизнес-логику.
Если это имеет значение, я работаю на PHP и MySQL, но меня интересуют предложения, которые могут быть закодированы на других языках.
ОБНОВЛЕНИЕ: Для более конкретного примера у меня есть таблица, называемая пользователем (в данном случае это имена таблиц в единственном числе), которая содержит такую информацию, как адрес электронной почты, активное состояние, имя пользователя, пароль, к какой компании они принадлежат и т.д. Этот базовый объект будет выглядеть так в коде:
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 и слой модели в упрощенную форму, которая сочетает в себе как любые функции реального типа (например, вход для пользователя), так и функции доступа к данным.
2 answers
Классы модели выделяются как хорошая, чистая, высокоточная модель объектов реального мира. Если это бизнес-область, то это могут быть клиенты, планы, продукты, платежи и все такое прочее. Ваше приложение работает с этими классами. Идея заключается в том, что ваше приложение представляет собой модель реальной обработки объектов домена. В вашем приложении могут быть функции методов, которые выглядят как глаголы, которые действительно делают люди, и реализация этих функций методов выглядит так описание реальных объектов реального мира.
Важно: Это (в идеале) не зависит от большинства технических соображений. Это самая чистая модель объектов предметной области, которую вы можете определить. [Да, у вас действительно есть проблемы с поиском по внешним ключам, и да, вам нужно информировать объекты модели о некоторых компонентах доступа к данным, чтобы объект модели мог находить объекты друг друга, используя только внешние ключи вместо фактического объекта. Хороший слой ORM решает эту проблему навигации для ты.]
Модель, полная SQL, не является хорошей моделью. Реальный мир тоже не полон SQL. Счет-фактура - это документ с некоторыми именами, адресами, товарами, датой доставки и тому подобным.
Классы доступа обрабатывают постоянное хранилище. Обычно это включает сопоставление объектов модели с таблицами реляционной базы данных. Ориентированный на SQL уровень доступа к данным восстановит вашу модель из реляционной базы данных и сохранит вашу модель в реляционной база данных. Уровень доступа к данным YAML будет считывать и записывать файлы YAML из вашей модели.
Иногда шаблон проектирования объектно-реляционного отображения (ORM) используется для четкого разделения мира SQL и вашей модели. Иногда объект доступа к данным (DAO) обрабатывает это разделение между SQL и моделью. Объект ORM или DAO может быть заполнен SQL.
Действительно, когда вы меняете продукты базы данных, только изменение происходит в DAO или ORM. Модель никогда не меняется, потому что он не зависит от SQL, YAML, JSON, XML или какого-либо другого метода сериализации.
Если ваш DAO создает и сохраняет объекты модели, я думаю, что у вас достаточно хорошо реализованы части модели MVC. Вы можете посмотреть пакеты ORM, чтобы получить дополнительные представления о состоянии техники. Я сам фанат ибАтиса.
Но это только 1/3 всего мировоззрения MVC. И - конечно - пуристы скажут вам, что MVC - это только рабочий стол или только smalltalk или отличается от общая веб-реализация MVC.
Это просто вопрос более высокой абстракции. Если вы думаете о какой-то бизнес-проблеме, которую собираетесь решить, вы хотите думать об этом с точки зрения концепций (сущностей, отношений, процессов и т.д.) этого бизнеса, а не с точки зрения объектов базы данных или на более детальном уровне, с точки зрения внутренних компонентов какой-либо конкретной системы баз данных (например. MySQL). Таким образом, вы можете смоделировать домен (т. Е. бизнеса и его правил) независимо от конкретной технологии, которую вы используете для реализация.
Другими словами, когда вы говорите "уровень доступа к данным", вы говорите о таблицах, строках, типах данных или даже о подходах к доступу к этим данным (например, с помощью шаблона активных записей), в то время как когда вы говорите о домене, вы говорите о бизнес-объектах, бизнес-правилах и бизнес-процессах.
И, кстати, при использовании шаблона MVC вы должны инкапсулировать бизнес-логику на уровне вашей модели (домена) (как я уже сказал выше), а не в контроллерах - они должны просто приведите в действие эти правила, так сказать.