Збереження моделі 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, що здійснюють підключення до БД та обробку даних.

Якщо вам цікаво, що таке ІРП, google для "PPI Framework".

Успіхів у пошуку.

З повагою, Пол Драгуніс.

Пам’ятайте, MVC виник у малій розмові, яка має автоматичну стійкість для всіх об’єктів. Таким чином, схема MVC не призначає жодного рішення для поділу моделі / стійкості.

Моя перевага - надати об’єкт "Репозиторій", який вміє створювати об'єкти Моделі з бази даних та зберігати модельні об'єкти в базі даних. Тоді Модель нічого не знає про наполегливість. Деякі дії користувача повинні викликати збереження, тому, ймовірно, Контролер буде знати про сховище. Зазвичай я використовую певну форму введення залежності, щоб запобігти приєднанню контролера до сховища.