Чому я повинен використовувати шаблон MVC?

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

Отже, навіщо мені використовувати MVC? Що я отримую, використовуючи MVC над простою відокремленням інтерфейсу від резервної логіки? (Більшість "переваг", які я бачу в цій шаблоні, отримуються лише шляхом відокремлення інтерфейсу від реалізації, і не вдається пояснити мету створення окремого "контролера")

Хе. Мартін Фаулер погоджується з вашою плутаниною щодо MVC:

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

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

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

Ви можете прочитати всю статтю Фоулера тут .

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

Модель - як ми представляємо дані? Наприклад, як я переходжу від своїх об'єктів до постійного сховища, такого як БД -> як я можу зберегти об'єкт "Користувач" в базі даних?

Контролер - що я роблю? Це те, що відбувається, і що на концептуальному рівні потрібно здійснити. Наприклад, які етапи потрібно пройти, щоб виставити рахунок-фактуру користувачеві? Примітка: це може впливати на будь-яку кількість об'єктів, але нічого не знає про те, як вони зберігаються в БД.

Перегляд - як я одержую результат?

Проблема, яку я відчуваю, полягає в тому, що багато веб-додатків - це прославлений інтерфейс CRUD (Create-Retrieve-Update-Delete) до БД. тобто контролеру кажуть "додати користувача", а потім він просто каже моделі "додати користувача". Нічого не отримується.

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

Ви не повинні.

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

Походячи з CI та Yii, я подумав, що мати виділений контролер - це справді класна ідея. Однак, коли розробляються програми з належними інтерфейсами RESTful, тоді потреба в контролері для обробки логіки, що не залежить від моделі, зменшується. Таким чином, переходячи до Django, а потім Pyramid (жодна з яких повністю не відповідає архітектурі MVC), я виявив, що контролер насправді не є необхідним компонентом для програм, які я будував. Зверніть увагу, що обидві рамки мають функції "контролера", такі як URL-адреса диспетчеризації в Pyramid, але це конфігурація, а не річ часу виконання (наприклад, CController в Yii).

Зрештою, що на насправді важливим є поділ зору від логіки. Це не тільки очищує речі з точки зору впровадження, але також дозволяє інженерам FE / BE працювати паралельно (під час роботи в командному середовищі).

(Побічна примітка: я не розробляю веб-додатки професійно, тому щось може пропустити)

Так, термінологія щодо цього - безлад. Важко говорити, тому що ти ніколи не знаєш, що хтось означає під термінами.

Щодо окремого контролера, причина може залежати від того, про яку версію контролера ви говорите.

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

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

Простіше кажучи: розділення проблем. Окрім усіх розмов про "правильний" спосіб роботи, чистіший код і т. Д., Ви можете просто сказати, що MVC дозволяє простіше використовувати код. В основному ви програмуєте свої моделі та контролери, і ви можете користуватися ними невиразно у веб-програмі, настільному додатку, сервісі та будь-де без особливих зусиль.

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

Я думаю, що MVC використовується просто словом теоретиків, які є менеджерами. Однак, сказавши це, нинішня ітерація Інтернету з поширеним HTML5, чуйним дизайном і намагається створити єдиний рядок програмування баз даних, який буде працювати в Інтернеті та на iPhone, піддається загальним ідеям MVC. Веб-технологія фронтального переходу буквально рухається зі швидкістю світла прямо зараз із Jquery, новими ітераціями управління CSS, тоді як серверна сторона речей рухається зі швидкістю равлика.

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

У зв'язку з цим, я вважаю, що в поточному реальному світі MVVM - це справді краща «модель» або як би ви цього хотіли назвати, ніж контролер, тому що контролер завжди повинен повертатися до моделі, щоб змінити погляд, і це повільно . У шаблоні MVVM ViewModel може негайно оновлювати перегляд. Крім того, модель MVVM просуває принципи RESTful дизайну IMHO.