Держать модель MVC свободно связанной с БД?

Мне нравится, чтобы мой код тестировался, и я решил использовать стратегию Dependency-Injection для моей текущей инфраструктуры MVC, которая, безусловно, оказалась отличным способом обеспечения слабосвязанного кода, тестируемости и модульности.

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

Как это можно сделать?
Поскольку я не предоставил никакого физического кода вместе с этим вопросом, я был бы очень признателен за некоторые примеры логики / кода или информацию, которая могла бы указать мне направление для понимания вышеописанной проблемы.

Одним из способов является разработка моделей до создания базы данных. При разработке ваших моделей основное внимание уделяется изучению бизнес-логики и значений в проблемной области. Это должно быть отражено таким образом, который имеет смысл для бизнеса, включая не только сущности и поля данных. Некоторые элементы данных интерпретируются от других, некоторые зависят от других и т. Д. Кроме того, вы добавили бы к этой модели любую базовую логику, которая вам нужна, например, как внутренний объект реагирует, когда для определенного элемента установлено определенное значение.

Вполне вероятно, что в конечном итоге вы получите что-то на 90 +% идентичное тому, как вы в конечном итоге сохраните данные. Хорошо. Это может быть полностью идентично, не будучи связанным.

Также обратите внимание, что моделирование домена в тумане истинного невежества является своего рода святым Граалем для разработки программного обеспечения. Если вы можете сделать это, фантастика. Но если проблемная область вообще значительна и имеет какую-то сложность, то все равно неплохо время от времени отступать от моделирования домена, чтобы проверять целостность данных, чтобы убедиться, что вы не нарисовали себя в угол.

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

1. База данных - храните данные, сохраняйте целостность данных, сохраняйте данные в покое.
2. Модели - содержат бизнес-логику, моделируют проблемную область, поддерживают движение данных, отвечают на события бизнес-уровня и т. Д.
3. Представления - представление данных пользователям, выполнение пользовательской логики (базовая проверка перед выполнением истинной проверки в моделях и т. Д.).
4. Контроллеры - отвечают на пользовательские события, передают управление моделям, направляют запросы и возвращают ответы.

Вы хотите иметь две вещи.

1. Ваши модели (обращаются к DBAL и выполняют большую часть логики приложения).

2. Ваши «доменные модели», то есть объекты данных, представляют объекты вашей системы, такие как пользователи, публикации, продукты и т. Д.

   class PPI_Model_User {
   
       protected $_conn = null;
   
       function __construct(array $options = array()) {
           if(isset($options['dsnData'])) {
               $this->_conn = new PPI_DataSource_PDO($options['dsnData']);
           }
       }
   
       function getAll() {
           $rows = $this->_connect->query("SELECT .....")->fetchAll();
           $users = array();
           foreach($rows as $row) {
               $users[] = new PPI_Entity_User($row);
           }
           return $users;
       }
   
   }

Код использования

    $model = new PPI_Model_User(array('dsnData' => $dsnData));
    $users = $model->getAll();
    foreach($users as $user) {
        echo $user->getFirstName();
    }

Там у вас это есть, вот как вы создаете модели предметной области (Entities) и имеете модели MVC, выполняющие подключение к БД и манипулирование данными.

Если вам интересно, что такое PPI, поищите в Google «PPI Framework».

Удачи в вашем поиске.

С уважением, Пол Драгунис.

Помните, MVC возник в smalltalk, который имеет автоматическое сохранение для всех объектов. Таким образом, шаблон MVC не предписывает никакого решения для разделения модели / персистентности.

Я предпочитаю предоставлять объект «Репозиторий», который знает, как создавать объекты модели из базы данных и сохранять объекты модели в базе данных. Тогда Модель ничего не знает о постоянстве. Тем не менее, некоторые действия пользователя должны инициировать сохранение, поэтому, скорее всего, контроллер будет знать о репозитории. Я обычно использую некоторую форму внедрения зависимостей, чтобы не допустить соединения контроллера с репозиторием.