Как Gang of Four Design Patterns се вписват в MVC парадигмата?

Моето лично мнение е, че MVC е опростена версия на модела на наблюдателя, който е опростена версия на шаблона на посредника.

MVC: Един модел, един изглед, контролерът управлява комуникацията между тях.

Модел на наблюдател: Един модел, множество изгледи (наблюдатели/абонати) и издателят управлява комуникацията

Модел на посредник: Няколко различни модела, няколко изгледа и посредникът управлява комуникациите между тях.

MVC в книгата GoF е за десктоп, той използва модела на наблюдател за актуализиране на изгледи. Примерът за команда в книгата GoF е за редактор.

Има и други разновидности на MVC, при които използването на други дизайнерски модели може да не е очевидно:
Каква е разликата между MVC и MVVM?
Контрол на абстракцията на презентацията

Книгата GoF казва:

...

Взет по номинална стойност, този пример отразява дизайн, който отделя изгледите от моделите. Но дизайнът е приложим към по-общ проблем: отделяне на обекти, така че промените в един да могат да засегнат произволен брой други, без да се изисква променения обект да знае подробности за другите. Този по-общ дизайн е описан от шаблона за проектиране Observer (страница 293).

Друга характеристика на MVC е, че изгледите могат да бъдат вложени. Например, контролен панел от бутони може да бъде реализиран като сложен изглед, съдържащ вложени изгледи на бутони. Потребителският интерфейс за обектен инспектор може да се състои от вложени изгледи, които могат да се използват повторно в програма за отстраняване на грешки. MVC поддържа вложени изгледи с класа CompositeView, подклас на View. CompositeView обектите действат точно като View обекти; съставен изглед може да се използва навсякъде, където може да се използва изглед, но също така съдържа и управлява вложени изгледи.

Отново можем да мислим за това като за дизайн, който ни позволява да третираме съставен изглед точно както третираме един от неговите компоненти. Но дизайнът е приложим за по-общ проблем, който възниква винаги, когато искаме да групираме обекти и да третираме групата като отделен обект. Този по-общ дизайн е описан от шаблона за проектиране Composite (163). Позволява ви да създадете йерархия на класове, в която някои подкласове дефинират примитивни обекти (напр. Button), а други класове дефинират съставни обекти (CompositeView), които сглобяват примитивите в по-сложни обекти.

MVC също така ви позволява да промените начина, по който даден изглед реагира на въвеждане от потребителя, без да променяте визуалното му представяне. Може да искате да промените начина, по който реагира на клавиатурата, например, или да го накарате да използва изскачащо меню вместо командни клавиши. MVC капсулира механизма за отговор в обект Controller. Има класова йерархия на контролери, което улеснява създаването на нов контролер като вариация на съществуващ.

Един изглед използва екземпляр на подклас Controller, за да приложи определена стратегия за отговор; за да приложите различна стратегия, просто заменете екземпляра с различен вид контролер. Възможно е дори да промените контролера на изгледа по време на изпълнение, за да позволите на изгледа да промени начина, по който реагира на потребителско въвеждане. Например изглед може да бъде деактивиран, така че да не приема входни данни, просто като му дадете контролер, който игнорира входни събития.

Връзката View-Controller е пример за шаблона за проектиране на стратегия (315). Стратегията е обект, който представлява алгоритъм. Полезно е, когато искате да замените алгоритъма статично или динамично, когато имате много варианти на алгоритъма или когато алгоритъмът има сложни структури от данни, които искате да капсулирате.

MVC използва други модели на проектиране, като Factory Method (107), за да определи класа на контролера по подразбиране за изглед и Decorator (175), за да добави превъртане към изглед. Но основните връзки в MVC са дадени от шаблоните за проектиране на наблюдателя, композита и стратегията.

...

MVC е модел. Но то обхваща само малък аспект на уеб приложение. Друг общ модел, който се използва с MVC, е Repository. Това са повече архитектурни модели... техният обхват има по-голямо влияние върху цялостния проект.

GOF моделите ще се представят по малки начини навсякъде. Те могат да помогнат за изграждането на MVC инфраструктура в зависимост от избора на дизайн. напр. стратегията се използва много, така че можете да включите различни начини за извършване на неща като "удостоверяване" и т.н.

Не е нужно да използвате моделите такива, каквито са, те дори не трябва да са абсолютно същата структура на кода. Това е по-скоро принципът/целта на дизайна на модела, който използвате в дизайна.

MVC е архитектурен шаблон. Перфектно се вписва с други дизайнерски модели като Command Pattern. Но вие не прилагате модели само защото съществуват и са написани в авторитетна книга. Прилагате шаблони, когато имате проблем с програмирането/проектирането и има начин да разрешите този проблем, който е открит от някой друг и е записан. Начинът за решаване на проблем е модел. Например, имате приложение, което записва данни в базата данни. Данните, които трябва да бъдат запазени, са доста сложни: някои записи трябва да бъдат вмъкнати, някои записи актуализирани и някои изтрити. Последователността на стъпките е важна, тъй като записите, които трябва да бъдат вмъкнати в една таблица, зависят от записите, които трябва да бъдат вмъкнати в друга таблица. Така че трябва да се използва транзакция на база данни. Един от възможните начини за реализиране на транзакцията е използването на команден шаблон. Начинът да го направите е много добре обяснен в „Прилагане на UML и шаблони" книга (глава „Проектиране на рамка за устойчивост с шаблони", раздел „Проектиране на транзакция с шаблона на командата“ - превъртете надолу до страница 556). PersistentObject там е абстрактен моделен клас. Всички други класове на модела го разширяват. В този пример MVC е внедрен в слоевете UI, Application и Domain, но Command е внедрен в слоя Persistence. Тези модели помагат за решаването на различни проблеми и се подкрепят взаимно в този пример.