Де M у MVC?

Я намагаюся змінити свою програму на MVC, але я застряг на M-частині.

У додатку, підтримуваному базою даних, модель реалізована в коді програми, правда?

Але тоді, що є в базі даних - це теж не модель?

(Я не використовую базу даних як простий сховище об'єктів - дані в БД є корпоративним активом).

Так, і модель в коді, і база даних є "Модель".

Модель має відношення до того, що ваша програма "IS", а контролер - це те, що "робить". Будь-який код, що має безпосереднє збереження в базі даних, вважається Модель.

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

Трігве Реенскауг написав початкові статті, що описували модель MVC ще в 1978 році. Модель в його описі була об'єктною моделлю, що представляє об'єкти, явища та концепції реального світу. У вашому сценарії програми, заснованої на базі даних, модель є проекцією ваших даних. Простіше кажучи, модель - це класи та їх взаємозв'язки, які стосуються вашої програми.

На практиці зазвичай існують дві моделі, що використовуються в MVC, Доменна модель (що відображається у вашій базі даних) та Прикладна модель (в сучасній термінології також називається Модель перегляду). Модель додатка - це проекція доменної моделі, яка також містить конкретні дані перегляду для надання подання. Такий підхід називається MMVC . Контролер безпосередньо взаємодіє з доменною моделлю і представляє представлену модель програми. У шаблоні MVVM поєднані модель програми та контролер.

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

2. Модель - це місце, де дані зберігаються у пам'яті у вашій програмі. Ви також хочете використовувати модель для обчислення та перевірки її даних. Наприклад, у вас є модель FinancePayment з такими властивостями, як процентна ставка, термін та принцип. Ви можете додати метод getMonthlyPayment () до своєї моделі для обчислення щомісячного платежу. Ви б не хотіли цього робити в контролері чи в режимі перегляду.

3. Погляд повинен бути досить тупим, або не мати логіки взагалі, або використовувати лише просте прив'язування даних (див. Пасивні форми перегляду та контролю за контролером на веб-сайті Мартіна Фаулера ). Перегляд викликає події, коли користувач робить такі речі, як-от натискання кнопки.

4. Контролер відповідає за обробку подій (запустіть якийсь код, коли користувач натискає кнопку збереження), а також за встановлення властивостей моделі та повідомляє моделі завантажуватись і зберігати себе (якщо використовується наполегливість). Контролер не повинен робити розрахунків за даними моделі. Однак у контролері ви можете зробити деякі обчислення від імені представлення даних, наприклад, "якщо model.profit () <0, то widget.colour = 'червоний" "

5. Ви повинні мати можливість перейти на версію програми з командним рядком, не змінюючи моделі та не втрачаючи функціональності моделей.

а. Ймовірно, ви зможете перейти на мобільну версію програми (на відміну від настільної версії), лише перемикаючи види (а не контролери та моделі). Ви повинні мати можливість протестувати свої моделі та контролери без рамки тестування GUI.

Модель - це код, який має підключення до V та C у передньому віці та до постійного сховища (може бути все, що завгодно, від файлів до баз даних SQL / NoSQL) у бекенді. Це не тільки код, який завантажується з db і зберігається в db (що є одним із непорозумінь моделі), це код, який насправді виконує всю роботу "домену" - вибирає, фільтрує, змінює, обчислює, приймає рішення над дані. Включає всю логіку програми, що не використовується UI.

Прийняття дуже спрощеного та ідеалістичного погляду.

Модель, як правило, розглядається як модель домену (орієнтовно, бізнес), а не як модель даних. Вони можуть виглядати схоже, але вони не повністю пов'язані один з одним.

Вид повинен бути моделлю переднього кінця програми, а Контролер повинен бути моделлю потоку від одного погляду до іншого.

Бізнес-логіка повинна бути повністю капсульована в Моделі, будь то в базі даних або в коді. Хоча певна ділова логіка може повторюватися в Перегляді або Контролері, з різних причин слід цілком (і безпечно) видалити ці два компоненти повністю і поставити на його місце інший передній край.

Наскільки я розумію, MVC - це лише опис архітектурної структури вашої клієнтської програми. Зображення тут у Вікіпедії як раз показує це:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Звичайно, коли у вас є частини вашої програми, реалізовані в "збережених процедурах", то цей код бази даних також може бути частиною моделі або навіть контролера (залежно від того, що робить код). Але якщо це не так, то база даних явно «поза MVC», як ви це заявили.

But then, what is in the database -- is that not also the model?

Ні, це не. " Модель керує поведінкою та даними домену додатка". Часто Модель зачіпає базу даних так, але жодним чином це не є вимогою. Модель є новим шаром між вашим додатком та базою даних. Захід може бути набором об'єктів Mock, XML або будь-яким іншим, що підтримує збереження даних.

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

Те саме стосується контролера. MVC визначає контролер як середню людину між двома шарами. У MVC не визначений "бізнес-шар". Швидше ви додасте своє. MVC не інкапсулює всі шари, необхідні для створення більшості програм. Це просто загальне керівництво для основної структури.

Ці розділення є ключовими для того, щоб дозволити функцію інверсії управління.

База даних - це деталізація реалізації моделі. Модель повинна бути повноцінною моделлю домену та повинна поєднувати дані та обробляти. Розмежування має бути між різницевими проблемами, а не між процесом та даними, пов'язаними з цим процесом.

Дивіться також: http://martinfowler.com/bliki/AnemicDomainModel.html

Насправді це дуже просто, "Модель" являє собою абстракцію для інтерфейсу даних. Ось чому:

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

І якщо я маю рацію - саме тому, коли хтось посилається на моделі поза контекстом MVC, хтось, швидше за все, посилається на структуру даних (тобто схему ).

Я думаю, що M містить деяку логіку і зберігає дані в БД. Контролер викликає, який модуль буде виконуватися, і цей модуль буде виконувати логіку та зберігати дані в БД (можливо, має стійкий рівень), а потім цей модуль повертає значення у В.

M (odel) у MVC має захоплювати модель бізнесу / домену в одному місці.

Це в ідеалі має включати бізнес-правила домену, а також його структуру.

C (контролер) в ідеалі стосується лише посередництва інформації бізнес-моделі до презентації (наприклад, Перегляд) та фіксації вводу користувача від V (iew) для ініціювання змін у стані моделі.

Шар бази даних має справу лише (вірніше, повинен мати справу лише з) збереженням стану моделі в певний момент часу.

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

Модель в ідеальному світі повинна містити лише ділову логіку, вона моделює якийсь реальний об'єкт, наприклад, Будинок. Однак майже в усіх обставинах моделі потрібно зберігати свої дані до деякого сховища.

Взаємодія між моделлю та збереженими даними може відбуватися або на окремому рівні даних, або безпосередньо в моделі, що є випадком використання ORM (Object Relational Mapper). Іншими словами, або модель підключається безпосередньо до бази даних, або передає свої дані іншому об'єкту "доступу до даних", який підключається до бази даних.

ORM (Object Relation Mapper) відображає поля в таблиці бази даних до атрибутів об'єкта моделі, надаючи геттерам та сетерам. У цьому випадку немає окремого рівня даних, і модель безпосередньо відповідає за збереження своїх даних.

Ось приклад Ruby з використанням ActiveRecordпопулярного ORM:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Priceявляє собою поле в housesтаблиці, яке автоматично виявляється, за допомогою ActiveRecordякого додається об’єкт getter та setter. Коли saveназивається, значення цінового атрибута зберігається в базі даних.

З моєї точки зору, про наявність рівня даних полягає в тому, що ви отримуєте точку, в якій можете маніпулювати даними, перш ніж потрапляти до моделі, модель менше турбується про неї, має менше обов'язків. Наприклад, вам може знадобитися об'єднати дані з кількох не сумісних джерел даних, це те, з чим ORM не може легко впоратися.

Основний мінус - це ще один шар абстракції для управління, якщо він вам не потрібен, не турбуйтеся, нехай це буде просто. Менше рухомих деталей, менше помилок.

Так, ти правий.

(Контролер перегляду моделі)

Архітектура для побудови програм, які відокремлюють дані (модель) від користувальницького інтерфейсу (подання) та обробки (контролера).

На практиці погляди та контролери MVC часто поєднуються в один об'єкт, оскільки вони тісно пов'язані. За даними MSDN

Контролер інтерпретує введення миші та клавіатури від користувача, інформуючи модель та / або the view to change as appropriate.

Перевірте цю схему:

Наприклад, код контролера перевіряє запит на дані і викликає повернення його у подання. Об'єкти контролера перегляду прив'язані лише до однієї моделі; проте,a model can have many view-controller objects associated with it.