Разница между уровнем доступа к данным и моделью в MVC

Question

Я реализовал то, что мне показалось довольно приличным представлением 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 and Model в упрощенную форму, которая сочетает в себе функции любого реального типа (например, вход в систему для пользователя) с функциями доступа к данным.

Answer 1

Классы модель стоят отдельно как хорошая, чистая, высококачественная модель реальных объектов. Если это бизнес-сфера, это могут быть клиенты, планы, продукты, платежи и все такое. Ваше приложение работает с этими классами. Идея заключается в том, что ваше приложение представляет собой модель реальной обработки доменных объектов. Ваше приложение может иметь функции методов, которые выглядят как глаголы, которые действительно делают люди, а реализация этих функций методов выглядит как описание реальных объектов в реальном мире.

Важно: Это (в идеале) не зависит от большинства технических соображений. Это самая чистая модель доменных объектов, которую вы можете определить. [Да, у вас есть проблемы с поиском внешнего ключа, и да, вам нужно сообщить объектам вашей модели о некоторых компонентах доступа к данным, чтобы объект модели мог находить объекты друг друга только по внешним ключам вместо реального объекта. Хороший слой ORM решает эту проблему для вас.]

Модель, полная SQL, не очень хорошая модель. Реальный мир тоже не полон SQL. Счет-фактура - это документ с некоторыми именами, адресами и товарами, датой отгрузки и множеством подобных вещей.

Классы access обрабатывают постоянное хранилище. Обычно это включает отображение объектов вашей модели в таблицы реляционной базы данных. Уровень доступа к данным, ориентированный на 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.

Answer 2

Это просто вопрос высшей абстракции. Если вы думаете о какой-то бизнес-проблеме, которую собираетесь решить, вы хотите думать о ней с точки зрения концепций (сущностей, отношений, процессов и т. Д.) Этого бизнеса, а не с точки зрения объектов базы данных или на более детальном уровне, в условия внутренних органов какой-либо конкретной системы баз данных (например, MySQL). Таким образом, вы можете моделировать домен (т. Е. Бизнес и его правила) независимо от конкретной технологии, которую вы используете для реализации.

Другими словами, когда вы говорите «уровень доступа к данным», вы говорите о таблицах, строках, типах данных или даже о подходах к доступу к этим данным (например, с помощью шаблона Active Record), когда вы говорите о домен, вы говорите о бизнес-объектах, бизнес-правилах и бизнес-процессах.

И, кстати, при использовании шаблона MVC вы должны инкапсулировать бизнес-логику на уровне модели (домена) (как я уже говорил выше), а не в контроллерах - они должны просто вызывать эти правила, так сказать.