Uživatelsky přívětivý přístup k vývoji webu: Model MVC. Jaký je návrhový vzor MVC v Javě

Bootstrap framework: rychlé adaptivní rozložení

Videokurz krok za krokem o základech adaptivního rozvržení v rámci Bootstrap.

Naučte se sázet jednoduše, rychle a efektivně pomocí výkonného a praktického nástroje.

Layout na objednávku a dostat zaplaceno.

Bezplatný kurz „Stránky na WordPressu“

Chcete ovládat WordPress CMS?

Získejte lekce o designu a rozložení webových stránek na WordPress.

Naučte se pracovat s motivy a stříhat rozvržení.

Zdarma video kurz kreslení návrhu webu, rozložení a instalace na CMS WordPress!

*Najetím myší pozastavíte rolování.

Zpět Vpřed

Přátelský přístup k vývoji webu: Model MVC

Co je MVC? Stručně řečeno, je to přístup k vývoji, který umožňuje dosáhnout strukturovanějšího kódu a aplikace jako celku.

MVC je zkratka pro Model-View-Controller. Promluvme si o tom podrobněji.

Dnes existují dva nejtypičtější způsoby vytváření webových aplikací (stránek).

První způsob, říkejme tomu "Classic", předpokládá, že jeden soubor může obsahovat kód z různých programovacích a značkovacích jazyků.

Řekněme, že na začátku souboru je proveden dotaz do databáze, abychom z ní získali nějaké informace. Zde máme co do činění s jazykem SQL – speciálním dotazovacím jazykem určeným pro interakci s databází.

Poté zpravidla začíná html značení stránky (kde bychom bez něj byli?). Navíc uvnitř html značky je na správná místa vložen PHP kód, který web ovládá a je jeho logikou. Celkem máme v jednom souboru: SQL, (X)HTML a PHP. To už je šmejd. Nezapomeňte sem přidat ještě nějaké CSS a trochu Javascriptu pro dokreslení a nakonec nám vznikne takový průšvih, že si v tomto souboru zlomí nohu sám ďábel.

Samozřejmě si nejprve zapamatujete, co a jak se v něm děje, proč to potřebujete a kde je potřeba provést změny, abyste přidali/odebrali/upravili určitou funkcionalitu. Garantuji vám však, že během několika měsíců budete na svůj kód koukat zmateně, snažit se zapamatovat si, co je s čím spojeno, jaké změny budou „implementovány“ po změně souboru atd.

Neříkám, že by se tento přístup měl úplně opustit, ale je jasné, že je třeba ho používat moudře a velmi opatrně.

Druhý způsob spojené právě s použitím schématu "Model-View-Controller".

Co je podstatou tohoto přístupu a jak vám jeho používání může pomoci ve vaší práci?

Hlavní myšlenkou tohoto přístupu je potřeba oddělení homogenních prvků do různých souborů. Velmi zjednodušeně řečeno: jeden soubor – jeden jazyk. Ale to je velmi drsný příklad. To je extrémně vzácné.

Kromě myšlenky ponechat různé jazyky v různých souborech je klíčový koncept také rozdělení souborů do skupin podle funkcí, které v aplikaci plní.

Zde začneme podrobněji přistupovat k modelu MVC.

Tento model zahrnuje rozdělení všech souborů zapojených do vývoje webu na tři skupiny:

1. Soubory skupiny "model".
2. Soubory skupiny "controller".
3. Soubory skupiny "view".

Zde je důležité okamžitě pochopit, že název schématu MVC je konvence. Vaše aplikace samozřejmě může mít mnoho modelů, ovladačů a pohledů (tedy souborů, které spadají do těchto skupin na základě funkcí, které vykonávají, a jejich vnitřní struktury).

Tak se podíváme srovnávací diagram modelu MVC a „klasické“ metody vývoje.

Na levé straně vidíte přesně to, o čem jsme mluvili výše. V horní části stránky jsou SQL dotazy do databáze. Poté značky plus vložky PHP.

Vpravo je nejjednodušší schéma modelu MVC. V rámci tohoto schématu v modelu probíhají operace související s interakcí s databází: získávání dat, jejich úprava a mazání, počítání počtu záznamů v určitých tabulkách atd.

Řadič obsahuje aplikační logiku, tj. to, co určuje jeho funkčnost.

Pohled je určen k zobrazení koncovému uživateli.

Obousměrné šipky v diagramu ukazují, že existuje vztah v párech „Model – Controller“ a „Controller – View“. Zvažme tento vztah podrobněji pomocí následujícího diagramu jako příkladu.

Do tohoto diagramu jsme přidali dva nové prvky: prohlížeč uživatele a databázi. Podívejme se na celý cyklus obecně: z prohlížeče přistupujícího ke konkrétní URL, dokud se stránka nezobrazí uživateli:

1. Uživatel zadá adresu a prohlížeč kontaktuje správce.

2. Ovladač přistupuje k modelu.

3. Model přistupuje k databázi (například za účelem získání informací nezbytných pro výstup)

4. Informace z databáze se vrátí zpět do modelu.

5. Informace se přenášejí z modelu do regulátoru.

6. Ovladač předá tyto informace pohledu.

7. Pohled se zobrazí v prohlížeči pomocí ovladače.

Toto je obecné schéma fungování tohoto modelu. Jak vidíte, prohlížeč a databáze vystupují na tomto diagramu poněkud odděleně. Opravdu, prohlížeč má přístup pouze k ovladači, protože ovladač je součástí adresy URL. Návštěvník nemá přístup k ničemu jinému než k ovladači. To je důležité pochopit. Osoba nemá přístup k zobrazením nebo modelům prostřednictvím adresního řádku. Spolupracuje pouze s ovladačem.

V tomto ohledu lze hovořit o regulátoru jako o jakémsi „distribučním centru“. Přesvědčte se sami: ovladač zpracovává požadavky uživatelů, ovladač přistupuje k modelu a ovladač je prostředníkem pro zobrazení pohledu v prohlížeči.

Druhým prvkem, který stojí stranou, je databáze. A je to tak. V rámci konceptu MVC je akceptováno, že S databází by měly pracovat pouze modely, někdy je však tato zásada porušována. V tomto případě se interakce s databází provádí z řadiče nebo dokonce z pohledu.

Samozřejmě byste neměli zacházet příliš daleko a porušovat strukturu a principy MVC, ale někdy může být takový odklon od pravidel velmi užitečný, pokud jde o zlepšení čitelnosti kódu a pochopení provozního schématu aplikace.

Model mimochodem, je volitelný prvek ve schématu MVC. Je zcela možné implementovat vše, co potřebujete, bez použití modelů. Přirozeně v tomto případě budete pracovat s databází z ovladače a prohlížet soubory. Jak jste již pochopili, toto není příliš dobrá forma. Jakmile se rozhodnete pracovat v rámci tohoto konceptu, doporučuje se používat modely a dělat tak pro jejich zamýšlený účel.

Prozkoumali jsme „extrémy“, ale naše trojice zůstala ve středu diagramu, kde se odehrávají interakce „Model – Controller“ a „Controller – View“.

Poté, co jsme si prostudovali základy tohoto modelu, můžeme přemýšlet o tom, co nám tento přístup dává a proč je výhodnější než ten klasický.

Hlavní přínos použití takového schématu ve vaší práci již byl zmíněn - toto zvýšení struktury kódu a aplikace jako celku. Není žádným tajemstvím, že model MVC přijalo mnoho výrobců frameworků, včetně mého oblíbeného CodeIgniter.

Koneckonců, co je to rámec? Pokud zahodíme cizí slovo, pak jde jednoduše o rámec, určitou strukturu, podle které se po vás žádá tvorba webu. Tato struktura je dostatečně univerzální na to, abyste s její pomocí vytvořili téměř jakýkoli web. Zároveň, což je velmi důležité, je rámec také velmi flexibilní a umožňuje vám dosáhnout přesně toho, co potřebujete.

Jinými slovy, framework je flexibilní framework, který vás omezuje z hlediska struktury, ale neomezuje vás z hlediska funkčnosti.

Vrátíme-li se k otázce o MVC, můžeme vidět, že mnoho frameworků používá přesně tento přístup: poskytují poměrně jasnou aplikační strukturu, která také rozděluje soubory na typy, modely a řadiče. To vše dohromady vám může ušetřit spoustu času, pokud jej jednou strávíte učením se, jak používat framework a model MVC.

Mezi další výhody modelu MVC patří rozdělení kódu podle funkčnosti. Už se nebudete muset prohrabávat změtí SQL dotazů, značek a PHP kódu. Pokud potřebujete něco opravit nebo změnit, budete přesně vědět, který soubor potřebujete upravit.

Níže můžete vidět část souboru patřícího do skupiny "views":

A zde je část kódu z modelu:

Takto může vypadat ovladač:

Velmi důležitou výhodou, jak vidíte, je oddělení pohledu od kódu. Často je potřeba nějak změnit design nebo i strukturu webu a přitom zachovat stejné informace na stránce, které se zobrazovaly dříve. A zde začíná úprava změť kódu, která je postupem času stále obtížnější.

Výhoda modelu MVC spočívá právě ve schopnosti kompletně vyloučit úpravy designu webu při změně logiky aplikace. Můžete změnit kterýkoli ze tří prvků: Model, View, Controller. V tomto případě nemusíte provádět změny ostatních prvků, protože jsou do určité míry autonomní.

Otázka autonomie je zvláště aktuální pro modely a druhy. Jakmile je napíšete, můžete je obvykle úspěšně použít pro různé projekty s minimálními nebo žádnými úpravami. To vám ušetří spoustu času přepisováním podobného kódu.

Výhody použití modelu MVC v rámci jsou zřejmé, například stejný CodeIgniter.

Není žádným tajemstvím, že každý web má velké množství podobných, nebo dokonce stejných funkcí. Stačí si zapamatovat formulář zpětné vazby nebo navigaci na stránce. To jsou jen ty nejvýraznější, „vnější“ momenty. Ještě více podobností najdete v kódu, který není pro běžného uživatele viditelný, v kódu, který běží na serveru.

Téměř všichni weboví vývojáři se potýkají s potřebou používat podobné funkce PHP, provádět podobné databázové dotazy atd. Výrobci frameworků zde udělali velmi důležitou věc – pokusili se ty funkce, které se používají nejčastěji, seskupit do samostatných souborů, čímž poskytli webmasterům a webovým programátorům nové možnosti.

Nyní můžete dělat často potřebné věci, aniž byste příliš přemýšleli o tom, jak budou implementovány. Místo několika desítek řádků můžete napsat několik řádků kódu, což ušetří váš čas a zaměřit se více na logiku toho, jak aplikace funguje, než na to, jak ji implementovat.

A to vše se děje v rámci konceptu MVC, který vám umožňuje dosáhnout téměř jakýchkoli výsledků pomocí rámce. Zároveň získáte vysokou míru čitelnosti kódu. Co ještě potřebujete pro pohodlnou a produktivní práci?

Doslov: Nezapomeňte, že jakákoliv struktura, která byla vytvořena za účelem usnadnění určitých úkolů, byla vytvořena proto, aby práci usnadnila.

Princip MVC byste neměli dodržovat v případech, kdy jste si jisti, že to má špatný vliv na vaše chápání struktury aplikace. Nejste to vy, kdo by se měl „ohýbat“ pod modelkou, ale modelka pod vámi.

Dmitrij Naumenko

P.S. Přemýšlíte, který PHP framework ovládat? Věnujte pozornost CakePHP – implementuje výše zmíněný vzor MVC a právě teď můžete získat krátký úvodní video kurz, abyste získali obecnou představu o možnostech tohoto rámce:

Líbil se vám materiál a chcete mi poděkovat?
Stačí sdílet se svými přáteli a kolegy!

V tomto článku porozumíme konceptu MVC a jak jej na příkladu můžeme aplikovat v PHP.

Koncept MVC

MVC(Model-view-controller, " Model-View-Behavior», « Model-View-Controller") je návrhový vzor aplikace, ve kterém je řídicí logika rozdělena do tří samostatných komponent tak, že úprava jedné z nich má minimální dopad na ostatní.

Šablonu MVC je dobré použít při vytváření složitých projektů, kde je potřeba oddělit práci PHP programátora (případně rozdělit skupinu programátorů na oddělení), designéra, designéra layoutu apod.

Vzor MVC odděluje zpracování prezentace, dat a uživatelské interakce do tří samostatných složek:

Model MVC(Model). Model poskytuje data (obvykle do View) a také reaguje na požadavky (obvykle z Controlleru) změnou svého stavu.

Zobrazení MVC(Pohled). Zodpovědnost za zobrazování informací (uživatelské rozhraní).

Chování MVC(Ovladač). Interpretuje vstup uživatele a informuje model a pohled, aby odpovídajícím způsobem reagovaly.

Pro objasnění akčního diagramu šablony MVC je uveden obrázek níže.

Komponenty jako prezentace a chování závisí na modelu, ale nijak jej neovlivňují. Model může mít více pohledů. Koncept MVC může být obtížné pochopit, ale jakmile jej pochopíte, stane se nepostradatelným při vývoji aplikací v PHP.

MVC v PHP

Zvláštností při použití MVC v PHP je, že existuje jeden vstupní bod do PHP aplikace, čehož je například dosaženo následovně. Vytvoří se soubor index.php, jehož prostřednictvím budou zpracovávány všechny požadavky. Chcete-li to provést, vytvořte ve složce s indexem soubor .htaccess a vložte do něj následující kód:

RewriteEngine na RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-d RewriteRule ^(.*)$ index.php?route=$1

V poskytnutém kódu první řádek zkontroluje existenci požadovaného souboru, a pokud neexistuje, je přesměrován na index.php, jinak budou do indexu přesměrovány i požadavky na obrázky stránek. Poslední řádek kódu převádí požadavky jako index.php?route=chat/index na index.php/chat/index. Pokud nemáte možnost používat ModRewrite ve své aplikaci, budete muset provést přesměrování ručně.

Model PHP

Údaje o modelu PHP jsou obsaženy v jeho atributech a lze je měnit pouze pomocí speciálních funkcí. Model může obsahovat několik pohledů. Zpravidla je phpmodel třída, která pracuje s databází, konkrétněji: zápis, čtení, mazání. Čtení informací z databáze lze samozřejmě realizovat několika pohledy (funkcemi). Jako příklad model článků na webu: můžete získat konkrétní článek z databáze, seznam nejnovějších, populárních, nějaké kategorie... to všechno jsou reprezentace modelu. Pro přehlednost je níže uveden příklad modelu php.

PHP kontrolér (chování)

PHP controllery přijímají požadavky uživatelů, které jsme odeslali přes index.php, a v souladu s nimi upravují chod modelu. Správnější by bylo říci, že ovládají chod aplikace PHP.

Zastoupení PHP

Pohled sleduje změny v modelu a vytváří nebo mění rozhraní php aplikace.

Seznam dat

jméno ?>

příjmení? >

Jak to funguje?PHPŠablona MVC?

Když uživatel přistoupí na požadovanou adresu URL, vybere se odpovídající ovladač, který přistupuje k pohledu a modelu, a zobrazí se informace. Jinými slovy, ovladač v mvc je spojovacím článkem mezi modelem a pohledem.

Výhody MVC šablony při vytváření PHP aplikace

Jak již bylo zmíněno výše, jedná se především o diferenciaci vývojářů PHP stránek na oddělení. Rychlost PHP aplikace se také zvyšuje, pokud je vytvořen velký projekt. Co se přímo týká samotného PHP vývojáře, je správné strukturování kódu PHP (vše je na svém místě, takže je to srozumitelnější).

Příklad MVC

Nebudeme se příliš soustředit na příklad toho, jak MVC funguje, protože jeden již máme, přidám několik dalších diagramů pro hlubší pochopení.

Další schéma, jak funguje šablona MVC v PHP, je více než snadné pochopit.

V online světě jsou rozesety miliony webových aplikací. Některé jsou docela jednoduché a jsou takové, u kterých by si „sám architekt matrice zlomil nohu“. Ale jedno mají společné - MVC.

Nejoblíbenější architektonický vzor ve světě mezi webovými aplikacemi - model-view-controller (Model View Controller nebo jednoduše MVC). Poprvé byl použit již koncem 70. let dvacátého století v aplikacích v jazyce Smalltalk. A pak se ho ujali programátoři Jáva a sdílel je s celým světem a všemi programovacími jazyky. PHP nebyla výjimkou. Dnes si jen malá část programátorů, kteří sbírají vzácný PHP kód, může dovolit neohlížet se směrem k MVC.

Stalo se tak populární z nějakého důvodu. Jednoduše se zrodilo pro vytváření flexibilních a škálovatelných aplikací, které se snadno udržují a rozšiřují.
Účelem našeho tutoriálu je na jednoduchém příkladu ukázat, jak funguje vzor MVC.

K dokončení úkolů budete potřebovat následující programy:

Poznámky:

• Předpokládáme, že máte základní znalosti PHP.

Vzor MVC

Nyní pojďme mluvit o všem v pořádku. Nejprve si odhalme velké tajemství zkratky, které zjevně odráží fakt, že aplikace se bude skládat ze tří vzájemně se ovlivňujících částí:

• Model je zodpovědný za správu dat, ukládá a získává entity používané aplikací, obvykle z databáze a obsahuje logiku implementovanou v aplikaci.
• Výkon odpovídá za zobrazení údajů poskytnutých správcem. S prezentací úzce souvisí koncept šablony, který umožňuje měnit vzhled zobrazovaných informací. Ve webové aplikaci je zobrazení často implementováno jako stránka HTML.
• Ovladač spojuje model a pohled. Přijímá požadavek od klienta, analyzuje jeho parametry a přistupuje k modelu, aby provedl operace s daty požadavku. Z modelu pocházejí již sestavené objekty. Poté jsou přesměrováni na pohled, který předá vygenerovanou stránku řadiči, který ji následně odešle klientovi.

Datové toky v tomto modelu lze schematicky znázornit takto:

Vstup do reality

Pojďme konečně formulovat skutečný problém. Řekněme, že nám nařídili vybudovat sociální síť. V tomto gigantickém úkolu je malý dílčí úkol: pomocí existující databáze přátel poskytnout zobrazení jejich kompletního seznamu a také podrobné informace o každém příteli.

Nebudeme se nyní zabývat architekturou celé sociální sítě. Vezmeme si jen malý dílčí úkol, představíme si jeho závažnost a aplikujeme na něj vzor MVC.

Jakmile jej začneme používat, hned nás napadne – jak uspořádat skripty našeho řešení tak, aby bylo vše po ruce? K tomu umístíme každou ze tří sekcí našeho systému MVC do samostatných složek a získáme tak jednoduchou adresářovou strukturu, ve které snadno najdeme to, co potřebujeme. Kromě toho umístíme tyto tři složky do adresáře lib a přesuneme jej nad kořenový webový adresář www:

/lib --/controller ---- FrendCnt.php --/model ---- Frend.php ---- FrendList.php --/view ---- frendlist.php ---- frendone.php / www -- index.php -- .htaccess

Nahrávání katalogu lib(obsahující engine našeho webu) z webového adresáře nám poskytuje větší zabezpečení, díky čemuž je náš systém nepřístupný zásahům hravých rukou hackerů.

Ovladač

Nyní pojďme mluvit o všem v pořádku. Začněme s ovladač, protože je to první ze tří komponent vzoru, který splňuje požadavek klienta, analyzuje jej na prvky a inicializuje objekty modelu. Poté, co model zpracuje data, přijme jejich odpověď a odešle je do prezentační vrstvy.

V našem jednoduchém příkladu bude kontrolér soustředěn do jediné třídy FrendCnt. Později si to popíšeme podrobněji A nyní něco málo o vstupním bodu do webové aplikace – tím bude samozřejmě soubor index.php. V něm určíme výchozí bod pro připojení našich skriptů. Vytvořme instanci řadiče a zavoláme na ní metodu, která začne zpracovávat HTTP požadavek a určí, co dál.

Výpis č. 1 (index souboru.php):

$baseDir = dirname(__FILE__) . "/.."; include_once($baseDir . "/lib/controller/FriendCnt.php"); $controller = new FriendCnt(); $controller->invoke();

Nyní o ovladači. Pro nás je to třída FriendCnt. Již jste si všimli, že instance této třídy je vytvořena v index.php. Má pouze jednu metodu invoke(), která je volána ihned po vytvoření instance. V konstruktoru kontroleru je vytvořen objekt na základě modelové třídy - FrendList (seznam přátel) pro práci s daty.

Ve funkci invoke() se na základě příchozího HTTP požadavku rozhoduje: jaká data jsou od modelu požadována. Poté se zavolá metoda, která načte data. Dále se připojují šablony pro zobrazení, do kterých se přenášejí data z regulátoru. Všimněte si, že řadič neví nic o databázi ani o tom, jak se stránka vykresluje.

Výpis č. 2 (soubor ovladače FriendCnt.php):

Require_once($baseDir . "/lib/model/FriendList.php"); class FriendCnt ( public $oFriendList; public function __construct() ( $this->oFriendList = new FriendList(); ) public function invoke() (global $baseDir; $oFriendList = $this->oFriendList; if(isset($_GET) ["klíč"])) ( $oFriendList->setKey($_GET["klíč"]); $oFriend = $oFriendList->fetch(); include $baseDir . "/lib/view/friendone.php"; ) else ( $aFriend = $oFriendList->fetch(); include $baseDir . "/lib/view/friendlist.php"; ) ) )

Model a entity

Model- to je obraz reality, ze kterého se bere jen to, co je potřeba k vyřešení problému. Model se zaměřuje na logiku řešení hlavního problému. Mnozí tomu říkají obchodní logika, nese to velkou odpovědnost:

• Ukládání, mazání, aktualizace dat aplikace. To je realizováno prostřednictvím databázových operací nebo prostřednictvím volání externích webových služeb.
• Zapouzdření veškeré aplikační logiky. Absolutně veškerá aplikační logika bez výjimky musí být soustředěna v modelu. Není potřeba přesouvat žádnou část obchodní logiky do ovladače nebo pohledu.

Náš model obsahuje dva skripty, z nichž každý má definovanou svou vlastní třídu. Centrální třída FriendList a třída entity Friend. V centrální třídě dochází k manipulaci s daty: přijímání dat od správce a jejich zpracování. Třída entity slouží jako kontejner pro přenos dat mezi modelem a pohledem a také definuje její formát. Při dobré implementaci vzoru MVC by se v řadiči neměly odkazovat na třídy entit a neměly by obsahovat žádnou obchodní logiku. Jejich účelem je pouze ukládat data.
Ve třídě FriendList, která pracuje se seznamem přátel, jsme vytvořili funkci, která modeluje interakci této třídy s databází. Metoda getFriendList() vrací pole objektů vytvořených ze třídy Friend. Pro usnadnění práce s daty byla vytvořena také funkce, která indexuje pole objektů. Kontrolér měl k dispozici pouze dvě metody: setKey() - nastavuje pole klíče, pomocí kterého jsou vrácena podrobná data o příteli; fetch() - vrátí buď konkrétní objekt, nebo celý seznam přátel.

Výpis č. 3 (modelový soubor FriendList.php):

Require_once($baseDir . "/lib/model/Friend.php"); class FriendList ( private $oneKey; soukromá funkce getFriendList() ( return array(new Friend("Alexander", "1985", " [e-mail chráněný]"), nový přítel ("Yuri", "1987", " [e-mail chráněný]"), nový přítel ("Alexey", "1989", " [e-mail chráněný]"),); ) soukromá funkce getIndexedList() ( $list = array(); foreach($this->getFriendList() jako $val) ( $list[$val->getKey()] = $val; ) return $list; ) veřejná funkce setKey($key) ( $this->oneKey = $key; ) veřejná funkce fetch() ( $aFriend = $this->getIndexedList(); return ($this->oneKey) ? $aFriend [$this->oneKey] : $aFriend;

V závislosti na implementaci objektů Entity mohou být data o nich formátována jako dokument XML nebo objekt JSON.

Výpis č. 4 (soubor entity Friend.php):

Class Friend ( soukromý $klíč; soukromý $jméno; soukromý $yearOfBirth; soukromý $email; veřejná funkce __construct($name, $yearOfBirth, $email) ( $this->key = md5($name . $yearOfBirth . $email) $this->name = $jmeno; $toto->e-mail = $email; ) veřejná funkce getName() ( return $this-; >name; ) veřejná funkce getYearOfBirth() ( return $this->yearOfBirth; ) public function getEmail() ( return $this->email; ) )

Výkon

Nyní potřebujeme prezentovat data v co nejlepším světle pro uživatele.

Je čas mluvit o prezentaci. V závislosti na úloze mohou být data předána pohledu v různých formátech: jednoduché objekty, dokumenty XML, objekty JSON atd. V našem případě je předán objekt nebo pole objektů. Zároveň jsme si nedělali starosti s výstupem základní vrstvy – co platí pro zápatí a záhlaví generované stránky, tento kód se opakuje v obou souborech zobrazení. Ale pro náš malý příklad to není důležité.

Hlavním bodem je ukázat, že pohled je oddělený od ovladače a modelu. V tomto případě je správce zodpovědný za přenos dat z modelu do pohledu.

V našem příkladu zobrazení obsahuje pouze dva soubory: jeden pro zobrazení podrobných informací o příteli a druhý pro zobrazení seznamu přátel.

Výpis č. 5 (soubor pro zobrazení seznamu přátel friendlist.php):

Jméno	Rok narození
getKey() ?>">getName() ?>	getYearOfBirth() ?>

Výpis č. 6 (soubor pro zobrazení seznamu přátel friendone.php):

getName() . "
"; echo "Rok narození: " . $oFriend->getYearOfBirth() ."
"; echo "E-mail: " . $oFriend->getEmail() ."
"; ?> Seznam

Pokud celý tento kód přenesete na webový server, pak ve výsledku nezískáte mikrostránku o dvou stránkách (soudě podle počtu prezentačních souborů), ale o čtyřech. První zobrazí seznam přátel a další tři zobrazí podrobné informace o každém příteli.

Mohli bychom implementovat procházení detailů pomocí AJAXu, pak bychom měli jen jednu stránku a část pohledu bychom renderovali přes JSON objekty přímo na počítačích klientů. V tomto ohledu je spousta možností.

Toto je zjednodušený příklad webové aplikace založené na vzoru MVC. Už na něm ale můžete vidět spoustu možností. Mezi výhody jsme již zahrnuli flexibilitu a škálovatelnost. Dalšími výhodami bude možnost standardizace kódování, snadná detekce a oprava chyb a rychlý vstup nových vývojářů do projektu. Kromě toho můžete změnit způsob ukládání entit ve vaší aplikaci pomocí webových služeb třetích stran a cloudových databází. Jedinou nevýhodou je mírné zvýšení objemu skriptů. A tak nepřetržité výhody. Tak to využijte pro své zdraví.

Zde jsou soubory projektu, stáhněte si a porovnejte:

Tak jak? jaké myšlenky? Pojďme komentovat, nestyďte se.

V tomto článku napíšeme „rámec“ našeho projektu. Slovem „framework“ mám na mysli pracovní kód, který bude založen na přístupu MVC, to znamená, že bude mít jasné rozdělení logiky na ovladače, akce, šablony (pohledy) a modely.

A tak začneme, jak jsem již psal v předchozím článku, vzor MVC implikuje jeden vstupní bod - index.php, všechny požadavky projdou tímto skriptem, bude přes něj fungovat veškerá logika projektu. Pro implementaci tohoto přístupu je nutné nakonfigurovat server, předpokládá se, že web běží na serveru Apache, takže nám stačí vytvořit soubor .htaccess, ve kterém zadáme pravidla směrování URL. Kromě určení vstupního bodu vám směrování umožňuje vytvářet CNC (lidsky čitelné adresy URL). To znamená, že po správné konfiguraci budou adresy stránek vypadat takto: site.ru/article/new.
Nejprve si vytvoříme .htaccess, který přesměruje zpracování všech stránek na skript index.php. Kód vypadá takto:

RewriteEngine na RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-d RewriteRule ^(.*)$ index.php?route=$1

Soubor .htaccess by měl být umístěn v kořenové složce webu a musíte okamžitě vytvořit skript index.php, který je vstupním bodem. Zapišme jeden řádek do index.php, abychom otestovali přesměrování:

Echo "test";

Nyní můžete zkontrolovat přesměrování, zadat libovolnou adresu a zjistit, co se stane: test-mvc.web/sdf/sdf/ nebo test-mvc.web/sdf/sdf/2342/v žádném případě na tom nezáleží, “ Test ". Pokud jste viděli tento nápis, znamená to, že jsme uspěli.
Pokračujme, pro pohodlí si v rootu webu vytvoříme soubor config.php, ve kterém nastavíme různé konstanty, které usnadní konfiguraci webu. Mohou to být různé cesty ke skriptům, databázové přístupy a tak dále. Nyní v konfiguraci nastavíme následující:

// Nastavte konstanty: define ("DS", DIRECTORY_SEPARATOR); // oddělovač pro cesty k souboru $sitePath = realpath(dirname(__FILE__) . DS); define("SITE_PATH", $sitePath); // cesta ke kořenové složce webu // pro připojení k databázi define("DB_USER", "root"); define("DB_PASS", ""); define("DB_HOST", "localhost"); define("DB_NAME", "blog_mvc");

Abychom mohli v celém projektu používat konstanty a další konfigurační data, musíme do souboru index.php zahrnout skript config.php.
Kromě připojení souboru nastavení je potřeba vytvořit připojení k databázi v index.php, propojit skript s jádrem webu a spustit router, ve kterém bude směrování probíhat.
Nyní, v pořádku, vytvoření připojení k databázi bude v index.php, takže připojení bude otevřeno pouze jednou. Jakmile otevřeme připojení, můžeme jej použít ve všech ovladačích a modelech, ale o tom později. Nyní už jen vytvoříme připojení k databázi. Pro práci s databází jsem se rozhodl použít PDO. Můžete si přečíst více o PDO.
Jádro webu umístíme do složky core a zavoláme skript core.php, zde napíšeme funkci, která se sama připojí, pro její fungování jsou nutné třídy. Tato funkce nám výrazně usnadní a zjednoduší práci s ovladači, modely atp. Protože při pohledu dopředu řeknu, že každý ovladač a každý model bude představovat samostatnou třídu.
Kromě automatického propojování tříd přidáme k jádru vytvoření úložiště (registru), do kterého budeme ukládat všechny potřebné objekty a proměnné, které se mohou kdekoli v projektu hodit.
Také připojíme router v indexovém souboru, analyzuje URL a připojí potřebný ovladač a akci. O tom, co je ovladač, jsem psal v předchozím článku a záměrně jsem vynechal informace o akci, aniž bych je zatěžoval zbytečnými informacemi. Co je tedy akce?
Controller je třída, která obsahuje různé metody s přístupem MVC, každá metoda bude akcí. To znamená, že akce je metoda třídy, která zpracuje data a přenese je do pohledu (do šablony). Možná to ještě není úplně jasné, ale po příkladu vše zapadne.
V této fázi stačí teorie, přejděme k praxi. Uvedu kód souborů, jejichž fungování jsem popsal výše.
Kód skriptu Index.php:

// povolení zobrazení všech chyb error_reporting (E_ALL); // připojení konfigurace include ("/config.php"); // Připojení k databázi $dbObject = new PDO("mysql:host=" . DB_HOST . ";dbname=" . DB_NAME, DB_USER, DB_PASS); // připojení jádra webu include (SITE_PATH . DS . "core" . DS . "core.php"); // Načtení routeru $router = new Router($registry); // zápis dat do registru $registry->set ("router", $router); // nastaví cestu ke složce controllers. $router->setPath(SITE_PATH . "řadiče"); //spuštění routeru $router->start();

Skript Core.php:

// Načítání tříd za běhu funkce __autoload($className) ( $filename = strtolower($className) . ".php"; // definujte třídu a najděte k ní cestu $expArr = explode("_", $className ) ; if(empty($expArr) OR $expArr == "Základ")( $složka = "třídy"; )else( switch(strtolower($expArr))( case "controller": $folder = "controllers"; break ; case "model": $složka = "modely"; výchozí: $složka; false ) // zahrnout soubor do třídy include ($file ) // spuštění registru (úložiště) $registry = new Registry;

Třída úložiště Registry.php bude umístěna ve složce /classes/

// Třída úložiště Registr tříd ( private $vars = array(); // sada funkcí záznamu dat ($key, $var) ( if (isset($this->vars[$key]) == true) ( ​​​​throw new Exception("Nelze nastavit var `" . $klíč . "`. Již nastaveno." ) $this->vars[$key] = $var return true; if (isset($this->vars[$key]) == false) ( return null; ) return $this->vars[$key] ) // odstranění datové funkce remove($var) ( unset($ this ->vars[$key]);

Kód souboru router.php, který se nachází ve složce /classes/

// třída routeru Třída Router ( private $registry; private $path; private $args = array(); // získání funkce úložiště __construct($registry) ( $this->registry = $registry; ) // nastavení cesty do složky s ovladači funkce setPath($cesta) ( $cesta = trim($cesta, "/\\"); $cesta .= DS; // pokud cesta neexistuje, signalizujte ji, pokud (is_dir($cesta ) == false ) ( vyvolá novou výjimku ("Neplatná cesta řadiče: `" . $cesta . "`"); ) $this->cesta = $cesta ) // definování řadiče a akce ze soukromé funkce URL getController( &$file, & $controller, &$action, &$args) ( $route = (empty($_GET["route"])) ? "" : $_GET["route"]; unset($_GET[" route"]); if (empty($route)) ( $route = "index"; ) // Získání částí URL $route = trim($route, "/\\"); $parts = explode(" /", $route); // Najděte řadič $cmd_path = $this->path; foreach ($parts jako $part) ( $fullpath = $cmd_path . $part; // Zkontrolujte, zda složka existuje, pokud (is_dir( $fullpath)) ( $cmd_path .= $ část . DS; array_shift($parts);

pokračovat; ) // Najděte soubor if (is_file($fullpath . ".php")) ( $controller = $part; array_shift($parts); break; ) ) // pokud URL neuvádí řadič, pak použijte default index if (empty ($controller)) ( $controller = "index"; ) // Získání akce $action = array_shift($parts);
if (empty($action)) ( $action = "index"; ) $file = $cmd_path . $controller. ".php";

// třída ovladače Controller_Index rozšiřuje Controller_Base ( // šablona public $layouts = "first_layouts"; // akční funkce index() ( $model = new Model_Users(); $userInfo = $model->getUser(); $this-> template->vars("userInfo", $userInfo $this->template->view("index" ));

Pro zobrazení (/views/index/index.php)

Testovací pohled
id:
jméno:

A model:

// třída modelu Model_Users( veřejná funkce getUser())( return array("id"=>1, "name"=>"test_name"); ) )

Jak jste si mohli všimnout, třída controller dědí z rodičovské třídy Controller_Base. To se provádí za účelem zjednodušení třídy regulátoru. Vzhledem k tomu, že pro práci se šablonami potřebujeme třídu ještě propojit, je její připojení umístěno v Controller_Base.
Dám jeho kód, je umístěn ve složce /classes/ a jmenuje se controller_base.php:

// abstraktní třída řadiče Abstract Class Controller_Base ( chráněný $registr; chráněný $šablona; chráněný $layouts; // veřejná šablona $vars = array(); // připojení šablon ve funkci konstruktoru __construct($registry) ( $this-> registry = $registry // šablony $this->template = new Template($this->layouts, get_class($this));

Teď už zbývá jen vymyslet šablony. V abstraktní třídě Controller_Base zavoláme třídu Template a předáme jí název šablony a název kontroleru.
Kód pro třídu Template, která se nachází zde /classes/ a jmenuje se template.php

// třída pro připojení šablon a předávání dat do šablony třídy zobrazení ( private $template; private $controller; private $layouts; private $vars = array(); funkce __construct($layouts, $controllerName) ( $this->layouts = $layouts; ( $this->vars[$varname]) == true) (nespouštěcí_chyba ("Nelze nastavit var `" . $varname . "`. Již nastaveno a přepis není povolen.", E_USER_NOTICE); return false; ) $this ->vars[$varname] = $value return true ) // zobrazení funkce view($name) ( $pathLayout = SITE_PATH . "views" . DS . "layouts" . DS . $this->layouts; ". php"; $obsah_PATH . " . $ this->layouts . "` neexistuje.", E_USER_NOTICE); návrat false; if (file_exists($contentPage) == false) ( trigger_error ("Šablona `" . $jméno . "` neexistuje.", E_USER_NOTICE);

vrátit false;
) foreach ($this->vars as $key => $value) ( ​​​​$$key = $value; ) include ($pathLayout);

))

Pokud jste si pozorně přečetli kód, pravděpodobně vám došlo, že pro zobrazení na stránkách používáme šablonu first_layouts a view (zobrazení) index.php - jeho kód jsem dal o něco výše. Zbývá nám pouze vytvořit soubor šablony first_layouts. Umístíme jej do složky /views/layouts/first_layouts.php

Šablona bude obsahovat následující kód:
záhlaví

Dobré odpoledne, vážení kolegové. V tomto článku bych chtěl mluvit o svém analytickém chápání rozdílů mezi vzory MVC, MVP a MVVM. K napsání tohoto článku mě přivedla touha porozumět moderním přístupům k vývoji velkého softwaru a odpovídajícím architektonickým prvkům. V současné fázi mého kariérního žebříčku nejsem přímým vývojářem, takže článek může obsahovat chyby, nepřesnosti a nedorozumění. Zajímá vás, jak analytici vidí, co dělají programátoři a architekti? Pak vítejte u kočky.

Odkazy

První věcí, kterou bych rád začal, jsou odkazy na externí materiály, které mě vedly při psaní tohoto článku:

Zavedení

V době, kdy slunce svítilo jasněji a tráva byla zelenější, vyvinul tým studentů, jako je autor tohoto článku, software napsáním stovek řádků kódu přímo do rozhraní produktu. Někdy byly pro práci s daty použity služby a manažeři a poté bylo řešení získáno pomocí vzoru Document-View. Podpora takového kódu vyžadovala enormní náklady, protože nový vývojář musel být vyškolen (řeknut), jaký kód je v produktu za co zodpovědný, a o nějakém testování jednotek se nemluvilo. Vývojový tým tvoří 4 lidé, kteří sedí v jedné místnosti.
Čas plynul, práce se změnila. Vyvíjené aplikace se staly většími a složitějšími a z jednoho soudržného týmu vývojářů vzniklo mnoho různých týmů vývojářů, architektů, specialistů na použitelnost, designérů a PM. Nyní je každý zodpovědný za svou vlastní oblast: GUI, obchodní logiku, komponenty. Objevilo se oddělení analýzy, testování a architektury. Náklady na vývoj softwaru stouply stokrát a dokonce tisíckrát. Tento přístup k vývoji vyžaduje stabilní architekturu, která by vzájemně synchronizovala různé funkční oblasti produktu.

Vzory

Vzhledem k cíli snížení mzdových nákladů na vývoj komplexního softwaru předpokládáme, že je nutné používat hotová unifikovaná řešení. Šablonové akce totiž usnadňují komunikaci mezi vývojáři, umožňují odkazovat na známé návrhy a snižují počet chyb.
Podle Wikipedie je návrhový vzor opakovatelný architektonický návrh, který představuje řešení designového problému v nějakém často se vyskytujícím kontextu.

Začněme první hlavní věcí – Model-View-Controller. MVC je základní vzor, ​​který si našel cestu do mnoha technologií, dal vzniknout novým technologiím a každý den usnadňuje život vývojářům.

Vzor MVC se poprvé objevil v jazyce SmallTalk. Vývojáři museli přijít s architektonickým řešením, které by oddělilo grafické rozhraní od obchodní logiky a obchodní logiku od dat. Ve své klasické verzi se tedy MVC skládá ze tří částí, které mu dávají jméno. Pojďme se na ně podívat:

Model

Model je obvykle chápán jako část obsahující funkční obchodní logiku aplikace. Model musí být zcela nezávislý na zbytku produktu. Vrstva modelu nemusí vědět nic o prvcích návrhu ani o tom, jak bude vykreslen. Je dosaženo výsledku, který vám umožní změnit prezentaci dat, způsob jejich zobrazení, aniž byste se dotkli samotného modelu.

Model má následující vlastnosti:

• Model je obchodní logikou aplikace;
• Model má znalosti o sobě a neví o ovladačích a pohledech;
• U některých projektů je model jednoduše datová vrstva (DAO, databáze, soubor XML);
• Pro jiné projekty je modelem správce databáze, sada objektů nebo jednoduše aplikační logika;

Pohled

Mezi povinnosti Pohledu patří zobrazování dat přijatých z Modelu. Pohled však nemůže přímo ovlivnit model. Můžeme říci, že pohled má k datům přístup pouze pro čtení.

Reprezentace má následující vlastnosti:

• Pohled implementuje zobrazení dat, která jsou získána z modelu jakýmkoli způsobem;
• V některých případech může mít pohled kód, který implementuje nějakou obchodní logiku.

Příklady prezentace: HTML stránka, WPF formulář, Windows Form.

Rozdíly mezi MVP & MVVM & MVP

Nejběžnější typy vzorů MVC jsou:

• Model-View-Controller
• Model-View-Presenter
• Model-View-View Model

Zvažme a porovnejme každý z nich.

Model-View-Presenter

Tento přístup umožňuje vytvořit reprezentační abstrakci. Chcete-li to provést, musíte vybrat rozhraní zobrazení se specifickou sadou vlastností a metod. Prezentující zase obdrží odkaz na implementaci rozhraní, přihlásí se k událostem prezentace a na požádání upraví model.

Známky moderátora:

• Pohled interaguje přímo s předvádějícím voláním příslušných funkcí nebo událostí v instanci předvádějícího;
• Prezentující komunikuje s Pohledem pomocí speciálního rozhraní implementovaného Pohledem;
• Jedna instance presenteru je přidružena k jednomu displeji.

Implementace:
Každý pohled musí implementovat odpovídající rozhraní. Prezentační rozhraní definuje sadu funkcí a událostí potřebných k interakci s uživatelem (např. IView.ShowErrorMessage(string msg)). Prezentující musí mít odkaz na implementaci odpovídajícího rozhraní, který je obvykle předán v konstruktoru.
Logika prezentace musí mít odkaz na instanci presenteru. Všechny události pohledu jsou předány ke zpracování prezentujícímu a téměř nikdy nejsou zpracovávány prezentační logikou (včetně vytváření dalších pohledů).

Příklad použití: Windows Forms.

Model-View-View Model

Tento přístup umožňuje přiřadit prvky pohledu k vlastnostem a událostem modelu pohledu. Lze namítnout, že každá vrstva tohoto vzoru neví o existenci další vrstvy.

Vlastnosti modelu View:

• Obousměrná komunikace s prezentací;
• Model pohledu je abstrakce pohledu. Obvykle to znamená, že vlastnosti pohledu jsou stejné jako vlastnosti pohledu/modelu
• Model pohledu nemá odkaz na rozhraní pohledu (IView). Změna stavu modelu pohledu automaticky změní pohled a naopak, protože se používá mechanismus vazby dat (Vazby)
• Jedna instance modelu pohledu je spojena s jedním pohledem.

Implementace:
Při použití tohoto vzoru pohled neimplementuje odpovídající rozhraní (IView).
Pohled musí mít odkaz na zdroj dat (DataContex), kterým je v tomto případě model pohledu. Prvky pohledu jsou svázány s odpovídajícími vlastnostmi a událostmi modelu pohledu.
Model pohledu zase implementuje speciální rozhraní, které se používá k automatické aktualizaci prvků pohledu. Příkladem takového rozhraní ve WPF by bylo INotifyPropertyChanged.

Příklad použití: WPF

Model-View-Controller

Hlavní myšlenkou tohoto vzoru je, že jak ovladač, tak pohled závisí na modelu, ale model nezávisí na těchto dvou komponentách.

Charakteristika regulátoru

• Ovladač určuje, který pohled se má v daný okamžik zobrazit;
• Události pohledu mohou ovlivnit pouze kontrolér Kontrolér může ovlivnit model a definovat jiný pohled.
• Pro jeden ovladač je možné více zobrazení;

Implementace:
Ovladač zachytí událost zvenčí a v souladu s logikou v ní vloženou na tuto událost reaguje změnou Modelu zavoláním příslušné metody. Po změně model použije událost, která se změnila, a všechny k odběru přihlášené události View se poté, co ji přijmou, obrátí na model pro aktualizovaná data, načež se zobrazí.

Příklad použití: MVC ASP.NET

Resumé

Implementace vzorů MVVM a MVP na první pohled vypadá docela jednoduše a podobně. Pro MVVM se však vazba pohledu na View-model provádí automaticky, ale pro MVP je nutné naprogramovat
Zdá se, že MVC má větší kontrolu nad pohledem.

Obecná pravidla pro výběr vzoru

MVVM

• Používá se v situaci, kdy je datová vazba možná bez nutnosti zavádět speciální rozhraní zobrazení (tj. není potřeba implementovat IView);
• Běžným příkladem je technologie WPF.

MVP

• Používá se v situaci, kdy není možná vazba dat (nelze použít vazbu);
• Běžným příkladem by bylo použití Windows Forms.

MVC

• Používá se v situaci, kdy není možná komunikace mezi pohledem a ostatními částmi aplikace (a nelze použít MVVM nebo MVP);
• Běžným případem použití je ASP.NET MVC.

Závěr

Na závěr by autor tohoto článku rád podotkl, že striktně se držet pouze jednoho vzoru není vždy tou nejlepší volbou. Představte si například, že byste chtěli použít MVVM k vývoji aplikací pomocí Windows Forms prostřednictvím vlastnosti Bindings ovládacích prvků. Vaším cílem je oddělit prezentaci od obchodní logiky a logiky, která je spojuje. Aplikace by měla být snadno testovatelná a podporována a srozumitelná pro analytiky (ostatně na otázku „jak se měří výkon pevného disku“ existuje pouze jedna správná odpověď – v joulech (abstraktní příklad Model -> Zobrazení)) .

Děkuji moc za váš čas, užijte si čtení!