| Modell-View-Controller | |
|---|---|
| angol Modell-View-Controller | |
| Szerkezet |
|
| Leírása: Tervezési minták | Nem |
A Model-View-Controller ( MVC , "Model-View-Controller", "Model-View-Controller") egy olyan séma, amely az alkalmazás adatait és a vezérlési logikát három különálló komponensre osztja: modellre, nézetre és vezérlőre - úgy, hogy a minden komponens önállóan kivitelezhető [1] .
Az MVC koncepcióját Trygve Reenskaug írta le 1978-ban [1] [2] , aki a Xerox PARC kutatóközpontban dolgozott a Smalltalk programozási nyelven . Később Steve Burbeck implementálta a mintát Smalltalk-80- ban [1] [3] [4] .
Az MVC koncepció végleges változata csak 1988-ban jelent meg a Technology Object folyóiratban [5] .
Ezt követően a tervezési minta fejlődésnek indult. Például bemutatták a HMVC hierarchikus változatát ; MVA , MVVM [6] [3] [4] .
A népszerűség további köre a Python , PHP és Ruby gyorstelepítési keretrendszereinek fejlesztése : Django , Laravel és Ruby on Rails . 2017-ben az MVC-vel rendelkező keretrendszerek előkelő helyet foglaltak el más, ezt a mintát nem tartalmazó keretrendszerekkel szemben [7] .
Az objektum-orientált programozás és a tervezési minták koncepciójának fejlődésével az MVC koncepció számos módosítása született, amelyek különböző szerzők által megvalósítva eltérhetnek az eredetitől. Így például Erian Vermi 2004-ben leírt egy példát egy általánosított MVC-re [8] .
Richard Pawson " Meztelen tárgyak " című disszertációjának előszavában Trygve Reenskaug megemlíti az MVC legkorábbi, kiadatlan változatát, amely szerint [9] :
Ennek a koncepciónak az alkalmazásának fő célja az üzleti logika ( modell ) elkülönítése a vizualizációtól ( nézet , nézet ). Ennek az elválasztásnak köszönhetően megnő a kód újrafelhasználásának lehetősége . Ez a koncepció akkor a leghasznosabb, ha a felhasználónak ugyanazt az adatot egyszerre kell látnia különböző kontextusokban és/vagy különböző nézőpontokból. Különösen a következő feladatokat hajtják végre:
Az MVC koncepció lehetővé teszi a modell, a nézet és a vezérlő három különálló részre történő szétválasztását:
A modell adatokat és módszereket biztosít a velük való munkavégzéshez: lekérdezések az adatbázisba, helyesség-ellenőrzés. A Modell független a Nézettől (nem tudja, hogyan kell megjeleníteni az adatokat) és a Vezérlőtől (nincs felhasználói interakciós pontja), csupán hozzáférést és kezelést biztosít az adatokhoz.
A modell úgy van felépítve, hogy állapotának megváltoztatásával válaszoljon a kérésekre, és beépíthető legyen a „ megfigyelők ” értesítése .
A modellnek a vizuális megjelenítéstől való függetlensége miatt több különböző reprezentációja is lehet egy "modellhez"
A nézet felelős azért, hogy a szükséges adatokat megkapja a modelltől és elküldje a felhasználónak. A nézet nem dolgozza fel a felhasználói bevitelt [10] .
A vezérlő biztosítja a „kommunikációt” a felhasználó és a rendszer között. Vezérli és irányítja az adatokat a felhasználótól a rendszerbe és fordítva. Modellt és nézetet használ a kívánt művelet végrehajtásához.
Mivel az MVC-nek nincs szigorú implementációja, többféleképpen is megvalósítható. Nincs általánosan elfogadott definíció arra vonatkozóan, hogy az üzleti logikát hol kell elhelyezni. Ez lehet a vezérlőben és a modellben is. Ez utóbbi esetben a modell minden üzleti objektumot tartalmazni fog minden adattal és funkcióval.
Egyes keretrendszerek mereven meghatározzák, hogy hova kell helyezni az üzleti logikát, mások nem rendelkeznek ilyen szabályokkal.
Szintén nincs meghatározva, hogy a felhasználó által bevitt adatok érvényesítésének hol kell lennie. Az egyszerű érvényesítések akár nézetben is előfordulhatnak, de ezek gyakoribbak egy vezérlőben vagy modellben.
Az adatok nemzetközivé tétele és formázása szintén nem tartalmaz egyértelmű útmutatást a helyszínre vonatkozóan.
A „Model-View-Controller” séma megvalósításához meglehetősen sok tervezési mintát használnak (az építészeti megoldás összetettségétől függően), amelyek közül a fő a „ megfigyelő ”, „ stratégia ”, „ linker ” [11 ] .
A legtipikusabb megvalósítás az, amikor a nézetet úgy választják el a modelltől, hogy egy interakciós protokollt hoznak létre közöttük, amely az „eseményapparátust” használja ( a program végrehajtása során felmerülő bizonyos helyzetek „események” általi kijelölése, értesítés küldése mindazoknak, akik feliratkoztak a fogadásra) : A modell belső adatainak minden konkrét változásáról ("eseményként" jelölve) értesíti azokat a tőle függő nézeteket, amelyek feliratkoztak az értesítésre - és a nézet frissítve. Így használatos a " megfigyelő " minta .
A felhasználói reakció feldolgozásakor a nézet a reakciótól függően kiválasztja a kívánt vezérlőt , amely valamilyen kapcsolatot biztosít a modellel. Ehhez a „ stratégiai ” mintát használjuk, vagy helyette a „ parancs ” mintát használjuk .
Az összetett-összetett hierarchikus típusú részobjektumok azonos típusú kezelésének lehetőségéhez a „ linker ” sablon használható . Ezenkívül más tervezési minták is használhatók - például a " gyári módszer ", amely lehetővé teszi az alapértelmezett vezérlőtípus beállítását a megfelelő nézethez.
A kezdő programozók nagyon gyakran passzív MVC-modellként értelmezik az MVC architektúra modellt: a modell kizárólag az adatok elérésére szolgáló funkciók halmazaként működik, a vezérlő pedig üzleti logikát tartalmaz . Ennek eredményeként a modellkód valójában egy eszköz az adatok DBMS -ből való lekérésére, a vezérlő pedig egy tipikus üzleti logikával megtöltött modul . Ennek a megértésnek köszönhetően az MVC fejlesztői elkezdtek olyan kódot írni, amelyet Padrigue Brady (a Zend Framework közösségi köreiben ismert ) "TTUK"-nak ("Fat Stupid Ugly Controllers"; Fat Stupid Ugly Controllers) írt le:
Az átlagos TTUK egy adatbázisból nyert adatokat (adatbázis-absztrakciós réteget használva, úgy tett, mintha modell lenne), vagy manipulálta, érvényesítette, megírta és átadta az adatokat egy nézetnek. Ez a megközelítés nagyon népszerűvé vált, mert az ilyen vezérlők használata hasonlít a klasszikus gyakorlathoz, amikor az alkalmazás minden oldalához külön php fájlt használnak.
— [ http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstood-and-unappreciated/ Az M az MVC-ben: Miért félreértik és nem értékelik a modelleketDe az objektum-orientált programozásban az aktív [12] MVC modellt használják, ahol a modell nemcsak az adathozzáférési kód és a DBMS kombinációja , hanem a teljes üzleti logika is ; a modellek más modelleket is magukba foglalhatnak . Az adatkezelők az információs rendszer elemeiként csak a következőkért felelősek:
A vezérlő csak ebben az esetben válik „vékonysá”, és kizárólag az információs rendszer egyes komponensei közötti kapcsolat (ragasztóréteg) funkcióját látja el .