| Model-View-Controller | |
|---|---|
| Angličtina Model-View-Controller | |
| Struktura |
|
| Popsáno v Návrhové vzory | Ne |
Model-View-Controller ( MVC , "Model-View-Controller", "Model-View-Controller") je schéma pro oddělení aplikačních dat a řídicí logiky do tří samostatných komponent: model, pohled a ovladač - takže modifikace každá složka může být provedena nezávisle [1] .
Koncept MVC popsal Trygve Reenskaug v roce 1978 [1] [2] , který pracoval ve výzkumném centru Xerox PARC na programovacím jazyku Smalltalk . Později Steve Burbeck implementoval vzor do Smalltalk-80 [1] [3] [4] .
Konečná verze konceptu MVC byla publikována až v roce 1988 v časopise Technology Object [5] .
Následně se designový vzor začal vyvíjet. Například byla představena hierarchická verze HMVC ; MVA , MVVM [6] [3] [4] .
Další kolo popularity přinesl vývoj rámců pro rychlé nasazení v Pythonu , PHP a Ruby : Django , Laravel a Ruby on Rails . V roce 2017 zaujaly rámce s MVC prominentní postavení ve vztahu k jiným rámcům bez tohoto vzoru [7] .
S rozvojem objektově orientovaného programování a konceptu návrhových vzorů vznikla řada modifikací konceptu MVC, které se při implementaci různými autory mohou od originálu lišit. Tak například Erian Vermi v roce 2004 popsal příklad zobecněného MVC [8] .
V předmluvě k disertační práci Richarda Pawsona „ Naked objects “ Trygve Reenskaug zmiňuje svou nepublikovanou nejstarší verzi MVC, podle které [9] :
Hlavním účelem aplikace tohoto konceptu je oddělit obchodní logiku ( model ) od její vizualizace ( view , view ). Díky tomuto oddělení se zvyšuje možnost opětovného použití kódu . Tento koncept je nejužitečnější, když uživatel potřebuje vidět stejná data ve stejnou dobu v různých kontextech a/nebo z různých úhlů pohledu. Zejména se plní následující úkoly:
Koncept MVC umožňuje rozdělit model, pohled a ovladač do tří samostatných komponent:
Model poskytuje data a metody pro práci s nimi: dotazy do databáze, kontrola správnosti. Model je nezávislý na View (neví, jak vykreslit data) a Controlleru (nemá žádné body interakce s uživatelem), pouze poskytuje přístup k datům a manipulaci s nimi.
Model je postaven tak, aby reagoval na požadavky změnou svého stavu a lze zabudovat upozornění „ pozorovatelů “ .
Model, díky nezávislosti na vizuální reprezentaci, může mít několik různých reprezentací pro jeden "model"
Pohled je zodpovědný za získání požadovaných dat z modelu a jejich odeslání uživateli. Pohled nezpracovává uživatelský vstup [10] .
Regulátor zajišťuje „komunikaci“ mezi uživatelem a systémem. Řídí a směruje data od uživatele do systému a naopak. Použije model a pohled k implementaci požadované akce.
Protože MVC nemá striktní implementaci, lze jej implementovat různými způsoby. Neexistuje žádná obecně přijímaná definice toho, kde by se obchodní logika měla nacházet. Může být jak v ovladači, tak v modelu. V druhém případě bude model obsahovat všechny obchodní objekty se všemi daty a funkcemi.
Některé rámce pevně definují, kam by měla být umístěna obchodní logika, jiné taková pravidla nemají.
Rovněž není specifikováno, kde by se mělo nacházet ověření uživatelem zadaných údajů. Jednoduché ověření může dokonce nastat v pohledu, ale jsou běžnější v řadiči nebo modelu.
Internacionalizace a formátování dat také postrádá jasné pokyny ohledně umístění.
K implementaci schématu „Model-View-Controller“ se používá poměrně velké množství návrhových vzorů (v závislosti na složitosti architektonického řešení), z nichž hlavní jsou „ pozorovatel “, „ strategie “, „ linker “ [11 ] .
Nejtypičtější implementací je, že pohled je oddělen od modelu vytvořením interakčního protokolu mezi nimi, který používá „aparát událostí“ (označení „událostmi“ určitých situací, které nastanou během provádění programu, a zasílání upozornění o všem, kteří se přihlásili k odběru): Při každé konkrétní změně interních dat v modelu (označené jako „událost“) upozorní ty pohledy, které jsou na něm závislé a které jsou přihlášeny k odběru takového upozornění – a pohled je aktualizováno. Takto se používá vzor „ pozorovatel “ .
Při zpracování reakce uživatele pohled vybere v závislosti na reakci požadovaný ovladač , který zajistí to či ono spojení s modelem. K tomu se používá vzor " strategie " nebo může být místo něj modifikován vzor " příkaz " .
Pro možnost stejného typu manipulace s dílčími objekty komplexně-složeného hierarchického typu lze použít šablonu „ linker “ . Kromě toho lze použít další návrhové vzory - například " tovární metoda ", která vám umožní nastavit výchozí typ ovladače pro odpovídající pohled.
Začínající programátoři velmi často interpretují architektonický model MVC jako pasivní model MVC: model funguje výhradně jako sada funkcí pro přístup k datům a kontrolér obsahuje obchodní logiku . V důsledku toho je kód modelu ve skutečnosti prostředkem pro získávání dat z DBMS a kontrolér je typický modul naplněný obchodní logikou. V důsledku tohoto porozumění začali vývojáři MVC psát kód, který Padrigue Brady (známý v kruzích komunity Zend Framework ) popsal jako „TTUK“ („Fat Stupid Ugly Controllers“; Fat Stupid Ugly Controllers):
Průměrný TTUK získával data z databáze (pomocí databázové abstraktní vrstvy, předstíral, že jde o model) nebo manipuloval, ověřoval, zapisoval a předával data do View. Tento přístup se stal velmi populárním, protože použití takových ovladačů je podobné klasické praxi používání samostatného php souboru pro každou stránku aplikace.
— [ http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/ The M in MVC: Why Models are Misunderstood and UnappreciatedAle v objektově orientovaném programování se používá aktivní model [12] MVC, kde model není pouze kombinací kódu pro přístup k datům a DBMS , ale také celé obchodní logiky ; modely mohou také v sobě zapouzdřit jiné modely. Správci jako prvky informačního systému zodpovídají pouze za:
Pouze v tomto případě se ovladač stává „tenkým“ a plní výhradně funkci spojnice (lepicí vrstvy) mezi jednotlivými komponentami informačního systému .