Де в системі MVC повинен стояти код стійкості бази даних?


21

Я бачив кілька конфігурацій для збереження інформації в базі даних. Як правило, в моєму куточку світу зазвичай зустрічаються три типи конструкцій:

  • Контролер керує стійкістю
  • Модель управляє стійкістю
  • Стороння бібліотека управляє стійкістю, зазвичай вимагаючи певних анотацій на моделі.

Мені цікаво, яка конфігурація (якщо така є) є концептуально найпростішою у використанні / найбільш сумісною з архітектурою MVC?

(Якщо це не той, який я вказав, будь ласка, дайте короткий контур / огляд як частину відповіді)

Відповіді:


13

Ваш другий і третій варіанти однакові. M у MVC - це не модель даних, а скоріше доменна модель. Сюди входить наполегливість, безпосередньо чи через ORM, і обидва цілком коректні.

Контролер повинен керувати потоком сайту і передає речі до домену (іноді через сервісний рівень), який потрібно обробляти, тому наполягати на тому, що це неправильно - або принаймні семантично незручно.


2
Я певною мірою не згоден. Конкретне використання стійкості - це логіка програми, і тому належить до шару програми, а не домену шару. Доменний рівень (містить модель домену) повинен не знати про наполегливість для випадкової бізнес-програми. Контролер є оркестром . Він може упорядкувати (дані) служби, інтерфейс користувача та доменну модель.
Сокіл

1
@Falcon: Хоча контролер повинен контролювати, коли дані завантажуються і зберігаються в базі даних, це абсолютно добре, щоб він сказав моделі зробити це. Використання ORM (стандартної або власної роликової) зазвичай означатиме сказати моделі завантажувати / зберігати, яка потім делегує ORM. Іншим способом може бути, щоб контролер повідомив ORM для завантаження / збереження чогось, передаючи йому клас моделі для завантаження (з критеріями вибору) або екземпляр моделі для збереження. У будь-якому випадку фактичне завантаження / збереження буде миттєво прив'язане до моделі.
Мар'ян Венема

@Marjan Venema: Так, я згоден, але питання полягає в тому, де цей код повинен жити. Я прагну тримати цю модель якомога більше невігласи щодо наполегливості та моделюю лише доменні утворення з їх поведінкою та взаємодіями. Все інше буде жити в шарах додатків (як це додаток моєї моделі). Картографування інформації / доступу до даних повністю відокремлено від доменної моделі, а також може забезпечити версію (оновлення / пониження). Застосування доступу до даних також живе у прикладних шарах (які містять служби, сховища тощо)
Falcon

@Falcon: Так, це хороший спосіб зробити це, як я це робив у минулому, використовуючи окремі класи картографування. Однак із появою розширеного RTTI (Delphi) та відображення (.Net та інших), я не маю жодних труднощів щодо використання цих даних у поєднанні з анотацією атрибутів моделі бізнес-об'єкта, щоб отримати все, і просто використовувати перевантаження, гачки коду в і / або спеціально закодовані класи ініціалізації, щоб подбати про версію бази даних.
Мар'ян Венема

5

Реально MVC - це здебільшого схема впровадження інтерфейсу, тому питання дещо суперечить. Однак дійсно є лише два варіанти великих зображень. Ваш контролер, як правило, розсилає запити для завантаження або збереження об'єктів у вашій моделі, використовуючи будь-який 1) сервісний рівень певного типу або 2) шаблон активного запису.

Сервісний рівень може приймати будь-яку з декількох форм, хоча мої особисті переваги - це робота з абстракцією сховища для сукупних кореневих сутностей, конкретні реалізації яких будуть працювати або з якоюсь ORM, або з легким DAO, або з API для деяких нереляційних магазинів, якщо це має сенс для програми.

Шаблон Active Record означає, що ваша модель несе відповідальність за стійкість, хоча зазвичай означає, що базовий клас керує відображенням вашого магазину, тому ваша модель насправді не так безпосередньо задіяна.

В основному, контролер розсилає запити на збереження об'єктів, будь то виклик до вашого сховища, ваша реалізація UnitOfWork або метод Save для ваших об'єктів. Якщо ви використовуєте сховища, об’єкти вашої моделі не знають стійкості.


3

У системі MVC (модель-перегляд-контролер) модель містить дані. Тому я вважаю, що в ній має бути наполегливість бази даних.


2

Більшість зразків MVC високого рівня, які я бачив, мають окремий infrastructureшар, який має фактичний код реалізації бази даних (тобто конкретні виклики NHibernate, EF або Linq або будь-який рівень ваших даних), в той час як "модельний" рівень (часто також рівень "Домен") має інтерфейси, що визначають послуги передачі даних.


0

Стандартна практика в MVC полягає в тому, щоб включати структуру даних та стійкість у шар M (odel).

Рівень моделі включає не лише класи (POCO тощо), які ви будете використовувати у вашій програмі. Вони містять сховища для цих класів.

Прикладом може бути сховище, де у вас є групи екземплярів класів даних, тобто:

Clients repository

AllClients()
RecentClients()
ClientByID(int id)

Ви зможете краще організувати свій модельний домен, а також матимете доступ до своїх даних різними способами, але все-таки шар даних / моделей буде компактним та надійним

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.