vzor Model-View-Controller

Kontext
Interaktivní aplikace s pružným rozhraním člověk-počítač.

Problém
Uživatelské rozhraní je náchylné v požadavcích na změny. Když rozšíříte funkcionalitu aplikace, musíte modifikovat přístup k menu o nové funkce. Různí uživatelé mají konfliktní požadavky na uživatelské rozhraní. Je-li uživatelské rozhraní těsně propojeno s funkcionálním jádrem aplikace je budování systému s uvedenou flexibilitou drahé a náchylné k chybám,. To ale vyústí v potřebu vývoje a údržby několika podstatně odlišných programových systémů, jeden pro každé uživatelské rozhraní.

Následující požadavky ovlivňují řešení:

• stejné informace jsou prezentovány odlišně v různých oknech, např. sloupcový graf, koláčový graf, číselná tabulka
• zobrazování a chování aplikace musí odrážet okamžitou manipulaci s daty
• změny v uživatelském rozhraní by měly být snadné a možné i za běhu programu
• podpora různých standardů a portování uživatelského rozhraní by neměla ovlivňovat kód jádra aplikace

Řešení
Model-View-Controller (MVC) byl poprvé uveden v objektově orientovaném programovém prostředí Smalltalk-80. MVC dělí interaktivní aplikaci na tři oblasti: zpracování (výpočet), vstupy, výstupy. Komponenta model zapouzdřuje základní data a funkcionalitu. Model je nezávislý na specifikacích vstupního a výstupního chování aplikace. Komponenta View (pohled) zobrazuje uživateli informace. View dostává data od modelu. Na model může existovat několik pohledů. Každá komponenta View je asociovaná s komponentou controller. Controllers dostávají vstup obyčejně jako události, které jsou způsobeny pohybem myši, stisknutím tlačítka myši, nebo stisknutím klávesy na klávesnici. Tyto události jsou transformovány na požadavky služeb pro model, nebo view. Uživatel má interakci se systémem výhradně prostřednictvím komponent controller.

Separace komponenty model od komponent view a controller umožňuje násobné pohledy na stejný model. Pokud uživatel změní model prostřednictvím komponenty controller jedné komponenty view, všechny ostatní komponenty view závislé na těchto datech se také změní. Komponenta model proto uvědomuje všechny komponenty view, zda-li se jejich data změnila. Komponenty view na druhou stranu obnovují data z komponenty model a aktualizují zobrazované informace. Mechanismus propagace změn je také popsán ve vzoru Publisher-Subscriber.

Publisher-Subscriber

Scénáře použití:
1. Ukazuje, jak uživatelský vstup, který způsobí změny v modelu, spouští mechanismus šíření změn.

• Komponenta controller akceptuje uživatelský vstup prostřednictvím své procedury zpracovávající události, interpretuje událost a aktivuje služební proceduru modelu.
  
• Komponenta model vykoná požadovanou službu. Výsledkem je změna interních dat.
  
• Komponenta model uvědomí všechny komponenty view (pohledy) a controllers registrované v mechanismu šíření změn o změnách voláním jejich update proceduru.
  
• Každá komponenta view pak samostatně požaduje změněná data na komponentě model a zobrazí je na obrazovce.
  
• Každá registrovaná komponenta controller obnoví data z modelu, aby umožnila,nebo zakázala jisté uživatelské funkce.
  
• Původní komponenta controller znovu získá řízení a vrací se z procedury zpracovávající událost.
  

Na obrázku je znázorněn 1. scénář pomocí diagramu sekvencí UML.

2. Ukazuje inicializaci MVC komponenty.

• Nejdříve je vytvořena instance komponenty model, která pak inicializuje vnitřní datové struktury.
  
• Je vytvořena instance komponenty view, která si bere odkaz na komponentu model, jako parametr inicializace.
  
• Komponenta view se registruje v mechanismu šíření změn modelu.
  
• Komponenta view pokračuje vytvořením controlleru. Controlleru předává jak referenci na sebe, tak i referenci na model.
  
• Komponenta controller se také registruje v mechanismu šíření změn modelu.
  
• Po inicializaci začne aplikace zpracovávat události.
  

Na obrázku je uveden 2. scénář (inicializace vzoru MVC) pomocí sekvenčního diagramu UML

Výhody

• Vícenásobné pohledy na stejný model.
• Synchronizované pohledy.
• Snadno zaměnitelné komponenty views a controllers.

Slabá místa

• Vzrůstající složitost.
• Rychle rostoucí počet operací update.
• Neefektivnost v přístupu k datům v pohledu.
• Nevyhnutelnost změn komponent views a controllers při portování.
• Problémy s použitím MVC s moderními nástroji uživatelského rozhraní.