Які падіння MVC? [зачинено]

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

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

Щоб звузити область, щоб це не закрилося, скажімо, для веб-додатків. Я працюю над бекендом і фронт-ендом для різних проектів, тому я не можу сказати лише фронт-енд або бекенд.

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

Це була моя найбільша помилка. Я довгий час розумів це просте правило:

• Не поширюйте шаблон MVC серед усієї програми,
• Обмежте його лише для інтерфейсу користувача.

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

Усі шаблони, які ви називаєте MVC-альтернативами (тобто Model-View-Presenter, Model-View-ViewModel), є лише способом реалізації загальної концепції MVC.

На мою думку, є два типи MVC - чистий і нечистий (за відсутністю кращого слова :)

Чистий MVC - це те, що було введено в невеликі розмови:

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

Інший (нечистий) MVC, який рекламується для веб-додатків, - це більше модель PAC ( Presentation-abstraction-control ) замість класичного MVC, наведеного вище. Більше про організацію коду та розділення проблем:

• Модель : Абстракція збережених даних
• Контроль : зазвичай відомий як рівень бізнес-логіки, а також частина програми, відповідальна за маршрутизацію HTTP-запитів до відповідної бізнес-логіки (ака-контролер)
• Перегляд : Переважно переглядайте шаблони, які форматують дані з моделі та повертають їх клієнту. Модель НІКОЛИ не надсилає оновлення для перегляду, а також подання не підписується на оновлення з моделі. Це був би кошмар. Отже, це більше схоже на PAC, ніж на справжній MVC.

Тепер ось як структурується веб-додаток:

1. Фронтальний : MVC для клієнта, що використовує фреймворки як Backbone.js тощо. Це, по суті, справжня форма MVC.
2. Бек-енд : знову ж таки, у вас є (нечистий) MVC / PAC для організації коду та розділення проблем
3. Глобальний веб-додаток (для веб-програми в цілому): Якщо у вас є RESTful сервер, який повертає лише дані JSON, то весь ваш сервер може сприйматися як модель для клієнтського додатка, де перегляд і контролер по суті знаходяться.

Отже, які є недоліки MVC ? Ну, модель витримала випробування часом, тому не так багато, що має значення, окрім того, що це трохи «складно». Розумієте, MVC - це складна модель - реалізує стратегію / зразок спостерігачів, і всі вони добре організовані для формування високоякісного шаблону.

Чи варто використовувати його скрізь? Можливо, не. Надзвичайно складні веб-програми, можливо, розбиті на кілька шарів! Можливо, ви не зможете піти лише з просторів перегляду / бізнес-логіки / даних. Загальна структура / організація все ще може бути MVC-ish, але лише на макроскопічному рівні.

Ось приклад, коли просто MVC сам по собі може бути поганим вибором : Спробуйте створити систему контролю повітряного руху або заявку на обробку позики / іпотеки для великого банку - просто MVC сам по собі був би поганим вибором. У вас неминуче з'являться шини подій / черги повідомлень, а також багатошарова архітектура з MVC в межах окремих шарів і, можливо, всебічний дизайн MVC / PAC, щоб зберегти базу коду краще організованою.

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

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

Щодо того, де його не використовувати. Ну, де б не застосовувався один елемент триплету MVC. Консольні програми можуть взагалі не реалізувати інтерфейс. Утилітні програми можуть не мати моделі. І, мабуть, якщо у вас немає ні моделі, ні виду, вам не потрібен контролер.

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

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

Альтернативою першої проблеми є відокремлення такого коду на незалежні підпроекти; альтернативою другому є не відокремлений код, або в класі, або в моделі файлу.

Я розумію, як застосовувати MVC / MV * - це принцип принципу розділення проблем (SoC) - розділення програми / кодів на окремі розділи / фрагменти, щоб кожен розділ міг вирішувати окрему проблему (посилання: http://en.wikipedia.org / wiki / відокремлення_файлів )

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

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

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

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