Разница между уровнем доступа к данным и моделью в MVC
Я реализовал то, что, как мне казалось, было довольно приличным представлением MVC в нескольких веб-приложениях, но с тех пор, как я присоединился к crackoverflow, я обнаружил, что, возможно, мои первоначальные определения были немного упрощенными, и поэтому мне бы очень хотелось пояснить различия между Уровень доступа к данным и уровень модели или домена веб-приложения.
В качестве контекста я в настоящее время использую объекты доступа к данным, которые реализуют функции CRUD для одной записи в таблице, которую представляет объект, а также функцию get (), которая возвращает объект, который позволяет мне перебирать все объекты, которые соответствуют критерии для функции get ().
На эти объекты доступа к данным ссылаются непосредственно из сценариев контроллера, которые содержат мою бизнес-логику.
Если это важно, я работаю с PHP и MySQL, но меня интересуют предложения, которые могут быть написаны на других языках.
ОБНОВИТЬ: В качестве более конкретного примера у меня есть таблица с именем user (здесь соглашение состоит из имен таблиц в единственном числе), которая содержит такую информацию, как адрес электронной почты, активное состояние, имя пользователя, пароль, компании, которой они принадлежат, и т. д. Этот базовый объект будет выглядеть как это в коде:
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 в упрощенную форму, которая сочетает в себе как любые функции реального мира (например, вход для пользователя), так и функции доступа к данным.
Ответы 2
Классы модель стоят особняком как хорошая, чистая, высокоточная модель реальных сущностей. Если это бизнес-домен, это могут быть клиенты, планы, продукты, платежи и все такое. Ваше приложение работает с этими классами. Идея состоит в том, что ваше приложение представляет собой модель реальной обработки объектов домена. В вашем приложении могут быть функции методов, которые выглядят как глаголы, которые действительно используют люди, и реализация этих функций методов выглядит как реальное описание реальных объектов.
Важно: это (в идеале) не зависит от большинства технических соображений. Это самая чистая модель объектов предметной области, которую вы можете определить. [Да, у вас действительно есть проблемы с поиском по внешнему ключу, и да, вам нужно сделать так, чтобы ваши объекты модели знали о некоторых компонентах доступа к данным, чтобы объект модели мог находить друг друга, используя только внешние ключи, а не реальный объект. Хороший уровень 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 - это только настольный компьютер или только smalltalk, или он отличается от обычной веб-реализации MVC.
Это просто вопрос высшей абстракции. Если вы думаете о какой-то бизнес-проблеме, которую собираетесь решить, вы хотите думать об этом с точки зрения концепций (сущностей, отношений, процессов и т. д.) Этого бизнеса, а не с точки зрения объектов базы данных или на более подробном уровне, в с точки зрения внутреннего устройства некоторой конкретной системы баз данных (например, MySQL). Таким образом, вы можете моделировать предметную область (т. Е. Бизнес и его правила) независимо от конкретной технологии, которую вы используете для реализации.
Другими словами, когда вы говорите «на уровне доступа к данным», вы говорите о таблицах, строках, типах данных или даже о подходах к доступу к этим данным (например, с использованием шаблона активной записи), а когда вы говорите о домене, вы поговорить о бизнес-объектах, бизнес-правилах и бизнес-процессах.
И, кстати, при использовании шаблона MVC вы должны инкапсулировать бизнес-логику на уровне вашей модели (домена) (как я сказал выше), а не в контроллерах - они должны просто запускать эти правила, так сказать.