Ovladač zobrazení modelu

Koncept ovladače modelu. Plná čára zde symbolizuje přímou asociaci , přerušovaná čára nepřímou asociaci (například prostřednictvím pozorovatele ).

Model View Controller ( MVC , anglicky pro ovládání prezentace modelu ) je vzor pro dělení softwaru na tříkomponentní datový model (anglický model ), prezentaci (anglický pohled ) a ovládání programu (anglický ovladač ). Vzor lze použít jak jako architektonický vzor,tak jako návrhový vzor. Cílem ukázky je vytvořit flexibilní návrh programu, který usnadní následné změny nebo rozšíření a umožní opětovné použití jednotlivých komponent. Poté je možné například napsat aplikaci, která používá stejný model, a poté ji zpřístupnit pro Windows, Mac, Linux nebo internet. Implementace používají stejný model, pouze ovladač a pohled musí být implementovány znovu.

Koncept MVC byl poprvé popsán v roce 1979 pro uživatelská rozhraní v Smalltalk podle Trygve Reenskaug (Seeheim model), který se pak pracuje na Smalltalk v Xerox PARC . Mezitím je však považován za de facto standard pro hrubý návrh mnoha komplexních softwarových systémů, někdy s rozlišením a často několika moduly, každý rozdělen podle vzoru MVC.

Klasický vzor architektury

Tyto tři komponenty na sobě závisí v různé míře v závislosti na implementaci:

Model ( model )

Model obsahuje data, která budou reprezentována prezentací. Je nezávislý na prezentaci a ovládání. Změny dat jsou prezentaci oznámeny šablonou návrhu „Observer“ . V některých implementacích vzoru MVC model obsahuje obchodní logiku, která je zodpovědná za úpravu dat.

Prezentace ( zobrazit )

Prezentace je zodpovědná za reprezentaci dat modelu a realizaci interakcí uživatelů. Zná model, jehož data prezentuje, ale není zodpovědný za zpracování těchto dat. Kromě toho je nezávislý na ovládání. Oznámení uživatelských interakcí ovládacímu prvku se provádí podle návrhového vzoru „pozorovatel“. Prezentace je upozorněna na změny dat v modelu pomocí vzoru návrhu Observer a poté může aktualizovat reprezentaci. Prezentace často používá návrhový vzor „složené slovo“ .

Ovládání ( ovladač )

Ovládací prvek spravuje prezentaci a model. Prezentace je informuje o interakcích uživatelů (pomocí návrhového vzoru „pozorovatel“ ), vyhodnotí je a poté provede úpravy prezentace a změny dat v modelu. V některých moderních implementacích vzoru MVC již řadič přímo neaktualizuje data v modelu, ale místo toho aktualizuje data nepřímo přístupem k obchodní logice implementované v modelu. Ve zvláštním případě vzoru MVC může ovládací prvek také spravovat několik prezentací nebo několik modelů současně.

Funkce nejsou specifikovány

Obchodní logika

Vzhledem k tomu, že vzor MVC musí být implementován odlišně v různých programovacích jazycích, neexistuje obecně použitelná definice toho, kde by měla být obchodní logika umístěna v rámci tříd MVC. Z historických důvodů je často stále naprogramován v řadiči, ale nyní je stále častěji implementován do modelu. Model obsahuje všechny obchodní objekty se všemi jejich daty a funkcemi, a proto je lze testovat izolovaně, rychle, úplně a automaticky. Některé rámce MVC striktně určují, kde implementovat obchodní logiku; jiné ponechávají toto rozhodnutí na vývojáři softwaru.

Ověření vstupu uživatele

Podobně není definováno umístění pro ověření vstupu uživatele. V zobrazení lze již implementovat jednoduché ověření formátu. Ověření, která musí více zohledňovat obchodní logiku , budou s větší pravděpodobností implementována do modelu nebo do řídicího systému.

Formátování dat a internacionalizace

Také pro formátování nezpracovaných dat a internacionalizaci není definováno, kde k tomu dochází. Z důvodu efektivity vývoje je často vhodné integrovat je do modelu, abyste se při prohlížení mohli omezit na vytváření widgetů nebo šablon. Na druhou stranu to posouvá aspekty reprezentace do modelu, což je v naprostém rozporu se základní myšlenkou. Jako variantu je proto také vhodné k tomu zajistit samostatné funkční oblasti, které pak nemusíte zahrnovat do modelu, pohledu nebo ovladače.

Dnešní implementace

Podmínky původního vzoru MVC jsou dnes často vypůjčeny, aby byly systémy srozumitelné a mnohem složitější než tehdejší software. Záleží na perspektivě uvažovaného subsystému, na které prvky se odkazuje. Webový prohlížeč lze chápat jako pohled na větší celkový systém, zatímco jeden formulářový prvek v prohlížeči se zase skládá z malého datového modelu, přidruženého zobrazení a jeho ovládání. Základní myšlenka oddělení modelu, pohledu a ovladače byla zachována, ale používá se jemněji granulovaným a vnořeným způsobem.

Ačkoli se mnoho projektů definuje jako architektura modelu-zobrazení-řadiče, tento termín se používá v mnoha různými způsoby. Prosazují se nové termíny jako Model-View-Presenter- , Model-View-ViewModel -nebo Model-View-Adapter , které se snaží varianty přesněji popsat.

Widgetové knihovny pro desktopové aplikace

Tyto jednotlivé složky grafických rozhraní, jako jsou položky menu nebo editor komponenty, jsou označovány jako widgety . Widgety se vyznačují tím, že kromě prezentace v jedné komponentě kombinují také typické vlastnosti klasického ovladače, například zpracování událostí. Některé widgety, jako např B. Seznamy pro výběr mohou mít dokonce svůj vlastní interní model, který pak musí být synchronizován se skutečným modelem.

Ačkoli widgety prorážejí pevné třícestné dělení, stále se mluví o architektuře model-view-controller. Existují také komponenty jako filtry pro třídění nebo potvrzovací dialogy, které nelze jednoznačně zařadit do klasického třícestného dělení.

Při použití knihoven widgetů ovladač ponechává část klasické funkce ovladače na widgetech a je omezen na ovládání modelu a případně dalších komponent pohledu.

Důležitost návrhového vzoru MVC bude ještě jasnější, když se postavíte do role vývojářů framework GUI . Problémem zde je, že v době vývoje widgetů ( zobrazení ) GUI není jisté, která technická data a datové struktury (model) mají být prezentovány a jaké technické procesy ( řízení ) mají být implementovány. Úkolem vývojáře rámce GUI je tedy poskytnout abstrakci pro model ve formě rozhraní. Obrázek jasně ukazuje, že jednotlivé části, jako je úložiště dat nebo vzhled, lze bez problémů vyměňovat.

Vzor návrhu MVC také definuje rámec pro vývojáře rozhraní GUI. Připravený rámec GUI obsahuje:

1. prezentace ( pohled ) ve formě implementovaných widgetů GUI ,
2. souhlas s podkladovým datovým modelem ve formě rozhraní,
3. dohoda o událostech (anglické události ) v důsledku interakce uživatele ve formě rozhraní a tříd a ausimplementierten
4. shoda událostí na základě změn modelu ve formě rozhraní a neimplementovaných tříd.

Interakce mezi serverem a prohlížečem ve webových aplikacích

V širším smyslu je vzor MVC pro webové aplikace distribuován mezi servery a prohlížeče, a je proto složitější než klasický vzor MVC. Abstraktně řečeno, prohlížeč přebírá viditelné zobrazení a přímý vstup uživatele, jakož i funkce a zobrazení, které nejsou specifické pro stránku. Server se stará o specifické ovládání prohlížeče tím, že s ním komunikuje přes HTTP .

V užším slova smyslu se rozumí pouze program na straně serveru. Je možné rozlišovat mezi webovým serverem pro statické weby a jeho delegováním na speciální doplňkové programy. Termín MVC se používá zejména v kontextu takových doplňkových programů pro webový server.

Modelka

Pro prohlížeč je stránka HTML datovým jádrem jejího modelu. Z pohledu celého systému jde pouze o pohled na celkový model, který je umístěn na serveru.

Pohled

Prohlížeč se stará o obecné funkce, jako je zobrazení textu, prvků formuláře a vložených objektů. Displej je specificky řízen zobrazovací programovou částí serveru pomocí odpovědi HTTP, hlavní část instrukce pro zobrazení se skládá ze stránky HTML.

Ovladač

Prohlížeč přijímá položky formuláře a odesílá je nebo přijímá odkaz, na který se kliká. V obou případech odešle požadavek HTTP na server. Část programu kontroleru zpracovává data požadavků HTTP a nakonec spouští vytvoření nového pohledu.

JavaScript

Webová stránka může obsahovat programový kód, obvykle JavaScript, např. B. pro validaci položek formuláře nebo řídicí logiky pro opětovné načítání obsahu na straně prohlížeče. Tento programový kód může být následně strukturován podle vzoru MVC, a tak jej lze považovat za součást celkového systému. Je třeba poznamenat, že použití logiky na straně klienta , která je strukturována podle vzoru MVC, musí být odlišeno od MVC použitého na straně serveru. Klient a server představují jednotlivé subsystémy. Takové webové aplikace jsou často prováděny v souladu s single-page paradigmatu .

Výdej s pozorovatelským vzorem

U klasických webových aplikací nemůže prohlížeč okamžitě reagovat na změny modelu na serveru podle klasického vzoru pozorovatele . Každá odpověď (odpověď HTTP) do prohlížeče vyžaduje požadavek (požadavek HTTP). Mluví se o cyklu požadavek-odpověď. Z toho vyplývá, že vzor pozorovatele nemůže ukázat své výhody ani na straně serveru. Protože by to znamenalo další práci, nebylo to obvykle používáno. Místo toho řadič obvykle funguje jako aktivní zprostředkovatel mezi modelem a zobrazením v rámci cyklu požadavku a odpovědi.

Novější webové aplikace již umožňují implementaci vzoru pozorovatele. Zde použitá technologie push (push serveru) umožňuje serveru přenášet události klientům přímo a bez požadavku. Mnoho implementací používá takzvaný dlouhý dotaz (požadavek se zpožděnou odpovědí, dokud nedojde k události) nebo novější webové zásuvky . Některé rámce JavaScriptu abstrahují proceduru push a používají „nejlepší“ postupy dostupné příslušným prohlížečem nebo serverovou aplikací. Je tedy také možné zavést vzor pozorovatele do webových aplikací.

Zvláštní výzvy hypertextových odkazů a akce formuláře

Hypertextový odkaz je vynikající funkcí webových aplikací . V klasické GUI aplikaci by zde v zobrazení bylo vytvořeno tlačítko, jehož událost kliknutí je spojena se změnou pohledu na základě jeho ID v ovladači. Přestože hypertextový odkaz také obsahuje ID, není jeho vlastní, ale cílovou adresou nového zobrazení. Totéž platí pro adresu akce formuláře HTML.

Oba jsou prvky ovladače pro uživatele prohlížeče, ale jejich funkční cíl je kódován na webových stránkách. To představuje výzvu k oddělení čistého zobrazení od funkčnosti adresy URL při vytváření webové stránky. Vývojář zobrazení by si neměl dělat starosti s často složitou funkcí řadiče adresy URL.

Rozdělení úkolů mezi pohled a ovladač lze snadno dosáhnout pomocí ID. Analogicky k aplikaci GUI je ID v řadiči propojeno s cílovou adresou. V zobrazení lze adresu URL vyvolat pomocí rozhraní pomocí ID nebo se ID použije jako zástupný symbol pro adresu URL, například v šabloně nebo ve formě propojovacích objektů ve stromu objektů.

Knihovny JavaScript a připojení AJAX

Zde je část programů architektury model-view-controller použita na straně klienta v prohlížeči, zatímco jiná část, zejména model, zůstává na serveru. Knihovny JavaScript poskytují celou řadu widgetů. Tyto aplikace jsou prostředníkem mezi webovými aplikacemi a knihovnami widgetů ve stylu desktopu.

Webové aplikace na straně serveru

Řadič na straně serveru obvykle vyhodnocuje příchozí data (požadavky) z prohlížeče. Obvykle působí jako moderátor mezi modelem a pohledem. Na straně serveru jsou tyto části programu míněny pohledem, který vytváří kód HTML pro odpověď (odpověď) . Zobrazení často funguje se šablonami HTML, jejichž zástupné symboly jsou nahrazeny daty modelu.

Řadič jako prostředník mezi modelem, zobrazením a webovým serverem

Typická funkční sekvence (bez přesměrování HTTP):

 Browser  -> HTTP-Request ->  Webserver -> Controller
                                                       <=> (beliebig häufig) Model oder View
 Browser  <- HTTP-Response <- Webserver <- Controller

Rozsah úkolů ovladače může být velmi variabilní. V nejjednodušším případě přiřadí pouze model a pohled. Může ale také převzít řadu dalších úkolů. To závisí na tom, jak aktivní nebo pasivní jsou model a pohled ve vztahu k validaci, internacionalizaci, obchodní logice, iteracím dat, když jsou vložena do pohledu, a ve vztahu k řadě dalších aspektů.

Postup se liší v závislosti na stylu osobního programování, webových serverech, programovacích jazycích, rámcích, používání jednotkových testů a požadavcích projektu. V případě programů PHP existuje např. B. programový tlumočník, který již zpracovává data požadavku HTTP a tím zase přebírá dílčí funkce klasického ovladače.

Přesměrování HTTP

Po změně modelu ( vytvoření nebo aktualizace ) se doporučuje přesměrování HTTP. Tato technika zabraňuje opakovanému odeslání omylem prostřednictvím načtení stránky. Navíc to odděluje zápis předchozího datového záznamu od čtení následujícího datového záznamu, takže lze řadiče rozumněji organizovat.

Pokud je ověření úspěšné, první požadavek, který se stále zabývá předchozím datovým záznamem, má přístup k zápisu do modelu. Poté proběhne přesměrování. Druhý požadavek má přístup ke čtení a již představuje další datový záznam ke zpracování. Pro uživatele prohlížeče to vypadá jako jediné volání.

 Browser  -> HTTP-Request  -> Webserver -> Controller -> positive Validierung -> Model (speichern der Daten nach Validierung)
 Browser  <- HTTP-Redirect <- Webserver <- Controller                                  (danach Redirect durch den Controller)
 Browser  -> HTTP-Request  -> Webserver -> Controller -> Model -> View                 (führt zu neuer Formularanfrage ohne Nutzeraktion)
 Browser  <- HTTP-Response <- Webserver <- Controller                                  (reguläre Response)

V případě neúspěšné validace je přijatý datový záznam naopak přímo znovu předložen ve stejné formě pro opravu. Neexistuje žádné přesměrování. Zpravidla také není nutné znovu dotazovat model.

 Browser  -> HTTP-Request ->  Webserver -> Controller -> negative Validierung -> View (Formular zur Überarbeitung der Eingaben)
 Browser  <- HTTP-Response <- Webserver <- Controller

Kaskáda ovladače

Aby bylo možné provést kontrolu rozsahu funkčnosti profesionálních webových stránek, musí být správce strukturován. Řadič je často strukturován jako kaskáda. Buď je ovladač aktivován na nejnižší úrovni kaskády, nebo se řadiče v průběhu kaskády větví stromově a vedou k vnoření výsledného pohledu.

Přední řadiče , řadiče a akce jsou často používané termíny pro třívrstvou strukturu řadičů. Tyto názvy odrážejí strukturu datových modelů a související datové operace. Na přední regulátor přejde do pohledu datového modelu, která je v centru pozornosti a kontrolovaném pomocí řídicí jednotky . Tyto akce jsou nejnižší hladiny Regulátor provádět operace s daty na tomto pohledu, které mohou být kombinovány s crud ( CRUD ).

Příkladem vnoření řadiče by mohla být webová stránka, kde zobrazení stránek kontroluje horní ovladač. Na druhé straně lze konkrétně použít několik bloků MVC současně na jedné straně, např. B. pro ústřední článek a pro různé kontextové informace.

Řadiče na straně serveru se vzorem modelu vzdálené prezentace

Model vzdálené prezentace je dalším vývojem vzoru MVC . V definici vzoru již existuje větší oddělení mezi pohledem a řadičem, což v mnoha oblastech usnadňuje outsourcing řadiče na server.

Příklad: MVC implementováno pomocí stránek JavaServer

Výše uvedený obrázek ukazuje model MVC pro jednoduchou registraci na webu. Uživatel (klient) nejprve požádá o stránku register.jsp. Jako odpověď obdrží stránku s formulářem HTML . Akce je validate.jspuvedeno ve formě . Po vyplnění formuláře tedy prohlížeč odešle zadaná data do validate.jsp, což je v tomto případě řídicí modul, a zkontroluje zadané hodnoty. Je odpovědný pouze za kontrolu a zpracování údajů. Samotnému validate.jspuživateli neposkytuje žádnou zpětnou vazbu. K ovládání převodů modul ovládání na odpovídající zobrazení . V tomto případě buď na, register.jsppokud byly položky neplatné, jinak na ok.jsp. Pokud je ovládací prvek předán zpět do register.jsp, register.jspuživatel znovu zobrazí formulář se z. B. chybová zpráva. Prohlížeč odešle opravená data zpět do validate.jsp. Pokud jsou položky správné, budou data přenesena do úložiště UsersBean. Ovládací prvek je poté ok.jsppředán do. To uživateli ukazuje například potvrzení úspěchu.

Viz také

• Interakce s kontextem dat je dalším vývojem a spíše komplementárním vzorem architektury.
• Chytré uživatelské rozhraní

literatura

• Erich Gamma, Richard Helm, Ralph Johnson: Design Pattern. Prvky opakovaně použitelného objektově orientovaného softwaru . 2. vydání. Addison-Wesley, ISBN 978-3-8273-1862-6 .

webové odkazy

• Steffen Düsel: Model-View-Controller (MVC) (německy)
• Portland Pattern Repository - Model View Controller (anglicky)
• Jeff Moore: Model View Controller (anglicky)
• GUI architektury . Martin Fowler (anglicky)

Individuální důkazy

1. ↑ Kamal Wickramanayake: Je MVC návrhovým vzorem nebo architektonickým vzorem? ( Anglicky ) In: Software View . 17. července 2010. Citováno 16. prosince 2016.