Modellvykontroller i tydligt språk. Introduktion till MVC onlinelektion
Du kanske till och med har hört talas om designmönster och till och med bläddrat igenom dessa underbara böcker:
- E. Gamma, R. Helm, R. Johnson, J. Vlissides "Objektiva tekniker orienterad design. Design mönster";
- M. Fowler "Arkitektur för företagsprogramvaruapplikationer."
Den här artikeln kommer att vara användbar främst för nybörjare. Jag hoppas i alla fall att du inom ett par timmar ska kunna få en uppfattning om implementeringen av MVC-mönstret, som ligger till grund för alla moderna webbramverk, och även få "mat" för vidare reflektion om "hur man gör det." I slutet av artikeln finns ett urval av användbara länkar som också hjälper dig att förstå vad webbramverk består av (förutom MVC) och hur de fungerar.
Vana PHP-programmerare kommer sannolikt inte att hitta något nytt för sig själva i den här artikeln, men deras kommentarer och kommentarer om huvudtexten skulle vara till stor hjälp! Därför att Utan teori är praktiken omöjlig, och utan praktiken är teorin värdelös, först blir det lite teori och sedan går vi vidare till praktiken. Om du redan är bekant med MVC-konceptet kan du hoppa över teoriavsnittet och gå direkt till praktiken.
1. Teori MVC-mönstret beskriver ett enkelt sätt att strukturera en applikation, vars syfte är att separera affärslogik från användargränssnittet. Som ett resultat är applikationen lättare att skala, testa, underhålla och naturligtvis implementera.Låt oss titta på det konceptuella diagrammet för MVC-mönstret (enligt min åsikt är detta det mest framgångsrika diagrammet jag har sett):
I arkitektur MVC-modell tillhandahåller data och affärslogikregler, vyn ansvarar för användargränssnitt, och styrenheten ger interaktion mellan modellen och vyn.
Ett typiskt flöde av en MVC-applikation kan beskrivas på följande sätt:
Detta visar vyn, säg hemsida webbplats.
som till exempel innehåller modellanrop som läser information från databasen.
Modellen ska inte interagera direkt med användaren. Alla variabler relaterade till användarförfrågan måste bearbetas i regulatorn.
Modellen ska inte generera HTML eller annan visningskod som kan ändras beroende på användarens behov. Sådan kod bör bearbetas i vyer.
Samma modell, till exempel: användarautentiseringsmodellen kan användas i både användar- och administrativa delar av applikationen. I det här fallet kan du lägga in den allmänna koden separat klass och ärva från det, definiera underapplikationsspecifika metoder i dess avkomlingar.
Visa - används för att specificera extern visning av data som tas emot från styrenheten och modellen.
Vyerna innehåller HTML-uppmärkning och små inlägg av PHP-kod för att gå igenom, formatera och visa data.
Bör inte komma direkt åt databasen. Detta är vad modeller ska göra.
Bör inte fungera med data som erhållits från en användarförfrågan. Denna uppgift måste utföras av kontrollanten.
Kan direkt komma åt egenskaper och metoder för en styrenhet eller modeller för att få utgångsklara data.
Vyer är vanligtvis uppdelade i en gemensam mall, som innehåller uppmärkning som är gemensam för alla sidor (till exempel en sidhuvud och sidfot) och delar av mallen som används för att visa datautdata från modellen eller visa datainmatningsformulär.
Styrenheten är limmet som kopplar ihop modeller, vyer och andra komponenter fungerande applikation. Den registeransvarige är ansvarig för att behandla användarförfrågningar. Styrenheten bör inte innehålla SQL-frågor. Det är bättre att hålla dem i modeller. Styrenheten bör inte innehålla HTML eller annan uppmärkning. Det är värt att ta upp det.
I en väldesignad MVC-applikation är styrenheter vanligtvis mycket tunna och innehåller bara några dussin rader kod. Vad kan man inte säga om Stupid Fat Controllers (SFC) i CMS Joomla. Styrlogiken är ganska typisk och det mesta överförs till basklasser.
Modeller, tvärtom, är väldigt tjocka och innehåller det mesta av koden relaterad till databehandling, eftersom datastrukturen och affärslogiken i den är vanligtvis ganska specifika för en viss applikation.
Jag hoppas att du redan har märkt att olika platser kan ha helt olika konstruktionsformat adressfält. Varje format kan visa arkitekturen för en webbapplikation. Även om detta inte alltid är fallet, är det i de flesta fall ett tydligt faktum.
Låt oss överväga två alternativ för adressfältet, som visar lite text och en användarprofil.
Ungefärlig bearbetningskod i det här fallet:
switch($_GET["action"]) (case "about" : require_once("about.php"); // "Om oss" sidbrytning; case "contacts" : require_once("contacts.php"); // "Kontakter" sidbrytning; case "feedback" : require_once("feedback.php");
Jag tror nästan alla har gjort det här förut.
Med hjälp av en URL-dirigeringsmotor kan du konfigurera din applikation att acceptera förfrågningar som denna för att visa samma information:
http://www.example.com/kontakter/feedback
Här representerar kontakter regulatorn och feedback är kontaktkontrollmetoden som visar formuläret respons etc. Vi återkommer till denna fråga i den praktiska delen.
Det är också värt att veta att många webbramverks routrar låter dig skapa anpassade URL-rutter (ange vad varje del av URL-adressen betyder) och regler för bearbetning av dem.
Nu har vi tillräcklig teoretisk kunskap för att gå vidare till praktiken.
Framöver kommer jag att säga att kärnklasserna Model, View och Controller kommer att lagras i kärnmappen.
Deras barn kommer att lagras i katalogerna för kontroller, modeller och vyer. Filen index.php är ingångspunkten till applikationen. Bootstrap.php-filen initierar laddningen av applikationen, ansluter alla nödvändiga moduler, etc.
Vi kommer att gå sekventiellt; Låt oss öppna filen index.php och fylla den med följande kod:
ini_set("display_errors", 1); require_once "application/bootstrap.php";
Det borde inte finnas några frågor här.
Låt oss sedan omedelbart gå till filen bootstrap.php:
require_once "core/model.php"; require_once "core/view.php"; require_once "core/controller.php"; require_once "core/route.php"; Route::start(); //starta routern
De första tre raderna kommer att inkludera för närvarande icke-existerande kärnfiler. Sista raderna anslut filen med routerklassen och starta den för körning genom att anropa den statiska startmetoden.
RewriteEngine On RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-d RewriteRule .* index.php [L]
Denna kod kommer att omdirigera all sidbearbetning till index.php, vilket är vad vi behöver. Kommer ni ihåg att vi i den första delen pratade om Front Controller?!
Vi kommer att placera routingen i en separat fil route.php i kärnkatalogen. I den här filen kommer vi att beskriva klassen Route, som kommer att köra kontrollermetoder, som i sin tur kommer att generera sidvyn.
Innehållet i filen route.php
class Route ( statisk funktion start() ( // controller och standardåtgärd $controller_name = "Main"; $action_name = "index"; $routes = explode("/", $_SERVER["REQUEST_URI"]); // get kontrollenhetens namn if (!empty($routes)) ( $controller_name = $routes; ) // få åtgärdsnamnet if (!empty($routes)) ( $action_name = $routes; ) // lägg till prefix $modellnamn = " Model_".$controller_name = "Controller_".$action_name = "action_".$action_name // koppla upp filen med modellklassen (det kanske inte finns en modellfil) $model_file = strtolower; ($model_name). ".php"; $model_path = "application/models/".$model_file; if(file_exists($model_path)) (inkludera "application/models/".$model_file;) med kontrollerklassen $controller_file = strtolower ($controller_name).php"; $controller_path = "application/controllers/".$controller_file; if(file_exists($controller_path)) (inkludera "application/controllers/".$controller_file; ) else ( /* det skulle vara korrekt att kasta ett undantag här, men för att förenkla saker och ting kommer vi omedelbart att omdirigera till 404-sidan */ Route::ErrorPage404(); ) // skapa en kontroller $controller = new $controller_name ; $action = $action_name; if(method_exists($controller, $action)) ( // anropa controller-åtgärden $controller->$action(); ) else ( // här skulle det också vara klokare att kasta ett undantag Route::ErrorPage404(); ) ) function ErrorPage404( ) ( $host = "http://".$_SERVER["HTTP_HOST"]."/"; header("HTTP/1.1 404 Not Found"); header("Status: 404 Not Found") ; header(" Plats:".$host."404");
Jag noterar att klassen implementerar mycket förenklad logik (trots den omfattande koden) och kan till och med ha säkerhetsproblem. Detta gjordes medvetet eftersom... att skriva en fullfjädrad routingklass förtjänar åtminstone en separat artikel. Låt oss titta på huvudpunkterna...
Det globala arrayelementet $_SERVER["REQUEST_URI"] innehåller den fullständiga adressen som användaren kontaktade.
Till exempel: example.ru/contacts/feedback
Använder funktionen explodera Adressen är uppdelad i komponenter. Som ett resultat får vi namnet på regulatorn, för det givna exemplet är detta regulator kontakter och namnet på handlingen, i vårt fall - respons.
Därefter ansluts modellfilen (modellen kan saknas) och styrenhetsfilen, om någon, och slutligen skapas en instans av styrenheten och åtgärden anropas, igen, om den beskrevs i styrenhetens klass.
Så när du går till till exempel adressen:
example.com/portfolio
eller
example.com/portfolio/index
Routern kommer att utföra följande åtgärder:
example.com/ufo
då kommer han att omdirigeras till sidan "404":
example.com/404
Samma sak kommer att hända om användaren kommer åt en åtgärd som inte beskrivs i styrenheten.2.2. Låt oss återgå till MVC-implementeringen Låt oss gå till kärnmappen och lägga till ytterligare tre filer till route.php-filen: model.php, view.php och controller.php
Låt mig påminna dig om att de kommer att innehålla basklasser, som vi nu ska börja skriva.
Innehållet i filen model.php
klassmodell ( offentlig funktion get_data() ( ) )
Modellklassen innehåller en enda tom datahämtningsmetod, som kommer att åsidosättas i underordnade klasser. När vi skapar efterkommande klasser blir allt tydligare.
Innehållet i filen view.php
class View ( //public $template_view; // här kan du ange standardvyn. funktion generera($content_view, $template_view, $data = null) ( /* if(is_array($data)) ( // convert array element till variabler extrahera($data ) */ inkluderar "application/views/".$template_view;
Det är inte svårt att gissa att metoden generera avsedda att bilda en uppfattning. Följande parametrar skickas till den:
för att visa innehållet på en specifik sida.
I vårt fall kommer den allmänna mallen att innehålla sidhuvud, meny, sidofält och sidfot, och sidinnehållet kommer att finnas i ett separat formulär. Återigen, detta görs för enkelhetens skull.
Innehållet i filen controller.php
class Controller ( public $model; public $view; function __construct() ( $this->view = new View(); ) funktion action_index() ( ) )
Metod action_index- detta är en åtgärd som anropas som standard, vi kommer att åsidosätta den när vi implementerar underordnade klasser.
I föregående figur är filen template_view.php markerad separat - detta är en mall som innehåller uppmärkning som är gemensam för alla sidor. I det enklaste fallet kan det se ut så här:
Hem
För att ge sajten ett presentabelt utseende designar vi CSS-mall och integrera den i vår webbplats genom att ändra strukturen för HTML-uppmärkningen och ansluta CSS- och JavaScript-filer:
I slutet av artikeln, i avsnittet "Resultat", finns en länk till ett GitHub-förråd med ett projekt där steg har vidtagits för att integrera en enkel mall.
class Controller_Main utökar Controller (funktion action_index() ( $this->view->generate("main_view.php", "template_view.php"); ) )
I metod generera en instans av klassen View, namnen på filerna i den allmänna mallen och vyn med sidinnehållet skickas.
Utöver indexåtgärden kan controllern naturligtvis innehålla andra åtgärder.
Vi har granskat den allmänna vyfilen tidigare. Tänk på innehållsfilen main_view.php:
Välkommen!
OLOLOSHA TEAM är ett team av förstklassiga specialister inom området webbutveckling med många års erfarenhet av att samla in mexikanska masker, brons- och stenstatyer från Indien och Ceylon, basreliefer och skulpturer skapade av mästare i Ekvatorialafrika fem eller sex århundraden sedan...
Finns här enkel markering utan PHP-anrop.
För att visa huvudsidan kan du använda en av följande adresser:
Vi kommer att överväga ett exempel med en vy som visar data erhållna från modellen nedan. 2.3.2. Skapa en "Portfolio"-sida I vårt fall är "Portfolio"-sidan den enda sidan som använder modellen.
Modellen inkluderar vanligtvis datasamplingsmetoder, till exempel:
Placera modellfilen model_portfolio.php i mappen models. Här är dess innehåll:
class Model_Portfolio utökar Model ( public function get_data() ( return array(array("Year" => "2012", "Site" => "http://DunkelBeer.ru", "Description" => "Reklamsida för mörk Dunkel-öl från den tyska tillverkaren Löwenbraü producerad i Ryssland av bryggeriföretaget "SUN InBev."), array("Year" => "2012", "Site" => "http://ZopoMobile.ru", "Description" " => "Ryskspråkig katalog kinesiska telefoner Zopo-företag baserat på Android OS och tillbehör för dem."), // todo); ) )
Modellkontrollerklassen finns i filen controller_portfolio.php, här är dess kod:
class Controller_Portfolio utökar Controller ( function __construct() ( $this->model = new Model_Portfolio(); $this->view = new View(); ) function action_index() ( $data = $this->model->get_data( ); $this->view->generate("portfolio_view.php", "template_view.php", $data ) )
Till en variabel data arrayen som returneras av metoden skrivs hämta data som vi tittade på tidigare.
Denna variabel skickas sedan som en metodparameter generera, som också innehåller: namnet på filen med den allmänna mallen och namnet på filen som innehåller vyn med sidans innehåll.
Vyn som innehåller sidinnehållet finns i portfolio_view.php-filen.
Portfölj
| År | Projekt | Beskrivning |
Allt är enkelt här, vyn visar data som erhållits från modellen. 2.3.3. Skapa de återstående sidorna De återstående sidorna skapas på samma sätt. Deras kod är tillgänglig i GitHub-förvaret, en länk till vilken finns i slutet av artikeln, i avsnittet "Resultat".3. Resultat Här är vad som hände till slut:
Skärmdump av den resulterande visitkortswebbplatsen
GitHub-länk: https://github.com/vitalyswipe/tinymvc/zipball/v0.1
Men i den här versionen skissade jag ut följande klasser (och deras motsvarande typer):
- Controller_Login där en vy genereras med ett formulär för inloggning och lösenord, efter att ha fyllts i vilket autentiseringsproceduren utförs och, om den lyckas, omdirigeras användaren till adminpanelen.
- Contorller_Admin med en indexåtgärd som kontrollerar om användaren tidigare var auktoriserad på webbplatsen som administratör (i så fall visas adminpanelvyn) och en utloggningsåtgärd för att logga ut.
Men att använda webbramverk som Yii eller Kohana, bestående av flera hundra filer, när man utvecklar enkla webbapplikationer (till exempel visitkortsajter) är inte alltid tillrådligt. Nu kan vi skapa en vacker MVC-modell för att inte blanda Php, Html, CSS och JavaScript-kod i en fil.
Den här artikeln är mer en utgångspunkt för att lära dig CMF än ett exempel på något riktigt korrekt som du kan använda som grund för din webbapplikation. Kanske har det till och med inspirerat dig och du funderar redan på att skriva ditt eget microframework eller CMS baserat på MVC. Men innan du återuppfinner nästa hjul med "blackjack och horor", tänk igen: det kanske vore mer rimligt att rikta dina ansträngningar på att utveckla och hjälpa gemenskapen av ett redan existerande projekt?!
P.S.: Artikeln skrevs om med hänsyn till några kommentarer som lämnats i kommentarerna. Kritiken visade sig vara mycket användbar. Att döma av svaret: kommentarer, PM och antalet användare som lagt till inlägget till favoriter, visade sig idén att skriva det här inlägget inte vara så dålig. Tyvärr går det inte att ta hänsyn till alla önskemål och skriva mer och mer i detalj på grund av tidsbrist... men kanske kommer de mystiska individerna som nedröstade originalversionen att göra detta. Lycka till med dina projekt!
5. Ett urval av användbara länkar om ämnet Artikeln berör mycket ofta ämnet webbramverk - detta är ett mycket brett ämne, eftersom även mikroramar består av många komponenter som är smart sammankopplade och det skulle krävas mer än en artikel för att prata om dessa komponenter. Jag bestämde mig dock för att här presentera ett litet urval av länkar (som jag följde när jag skrev den här artikeln) som på ett eller annat sätt relaterar till ämnet ramverk.Taggar: Lägg till taggar
MVC (Model-View-Controller) är en mycket använd utvecklingsteknik (mönster).Idag är detta det mest populära mönstret som används inom webbutveckling.
I denna föreläsningskurs kommer vi att skapa ett MVC-ramverk och enkelt CMS, som bygger på den.
Detta CMS kommer att ha flera kontroller för att arbeta med artiklar, användare och ett feedbackformulär, samt en adminpanel.
Modeller, vyer, kontroller är speciella nödvändiga delar av en webbapplikation.
Nyckelprinciper för MVC:
Modeller - ansvarig för applikationsdata och databasåtkomst;
Kontrollanter ansvarar för användarinteraktion med systemet.
Vid behov får regulatorer data från modeller.
Representationer (med andra ord, HTML-mallar) - helt enkelt visa data som tagits emot från styrenheten.
Det finns inget direkt samband mellan åsikter och modeller.
MVC-applikationer har många fördelar som:
- lätt att förstå och lätt att utveckla;
- hög grad flexibilitet;
- enkelt kodstöd;
- snabb utveckling.
Det är därför många applikationer och världsberömda ramverk
baserad på MVC.
Låt oss ta en titt på en kommersiell webbplats som ett exempel:
Som regel består den av minst flera huvudmoduler:
- Produktmodul, som ansvarar för att visa produkter, söka och visa;
- Kundvagnsmodul, som ansvarar för att lägga och behandla beställningar;
- Användarmodul – ansvarig för att registrera användare och hantera konton.
I MVC-termer har denna applikation följande struktur:
ProductsController klass med metoder (funktioner) index (visa en lista över produkter),
visa (visar en produkt), sök (sök på produkt). Dessa metoder kallas åtgärder.
Denna styrenhet interagerar med produktklassen (modellen), som kommer att innehålla metoder för
komma åt och hantera produktdata, såsom getProductsList, search, getProductById,
spara, radera osv.
ProductsController innehåller även metoder för adminpanelen. Till exempel är admin_edit för
redigera produkten eller admin_view - för att visa produkten i adminpanelen.
Strukturen för modulerna Kundvagn och Användare liknar strukturen för Produktmodulen.
Genom att använda denna standardstruktur kan vi separera koden för olika
logiska delar eller "moduler" av vår applikation för att öka
produktivitet och undvika misstag.
Vi kan vara säkra på att om detta är en produktmodell så innehåller den inte kod för att hantera användare och vice versa.
Dessutom separerar vi på detta sätt PHP, HTML, JS och SQL-koder.
På så sätt blir koden renare och mer begriplig.
Låt oss titta på hur förfrågningar behandlas i MVC.
En MVC-applikation kräver att URL:en byggs i en specifik form.
Angående exemplet på en kommersiell webbplats som vi nämnde ovan, om vi vill
för att komma till produktinformationssidan måste vi gå till följande URL:
http://din-webbplats.com/produkter
I I detta fall, produkter är namnet på kontrollanten och namnet på åtgärden är index, av
standard. Om vi vill se en specifik produkt kommer det att vara det
http://your-site.com/products/view/11.
Vi tror att du redan har sett liknande webbadresser.
Sådana webbadresser kallas Användarvänlig (dvs användarvänlig URL) eller CNC (läsbar URL).
Därför är produkt här namnet på kontrollern, och namnet på vyn och åtgärden är index.
I URL:en är 11 parametern för åtgärd. I det här fallet kommer det att vara produkt-id.
Egentligen är en registeransvarig en del av en applikation som ansvarar för vissa
tomter. Till exempel kommer användare, produkter, sidor att vara olika kontroller. Alla operationer
som kan produceras i applikationen implementeras i controllers som offentliga metoder.
Till exempel kommer användarkontrollanten att innehålla metodregister, inloggning, utloggning, etc.
All data som visas för användaren skickas från kontrollören till vyer, d.v.s. V
HTML-mallar. Typiskt har varje styrmetod en motsvarande vy.
Låt oss titta på hur förfrågningar behandlas på en MVC-webbplats.
Det är ganska enkelt.
1. Använd en speciell .htaccess-fil, alla förfrågningar som inte är det
filförfrågningar omdirigeras till filen index.php.
2. Nästa steg är att ringa samordnaren. Samordnaren analyserar URL:en för att få
controller och åtgärdsnamn. Andra parametrar erhålls också från begäran. Detta
kanske till exempel en språkkod.
3. När en lämplig kontrollenhet och kontrollmetodnamn har fastställts,
Kontrollmetoden kallas.
4. Controllermetoden anropar sedan modellerna metoder för att få data.
5. När det är dags att tillhandahålla data till användaren
visa motsvarande vy. All data som returneras
genom kontrollmetoden skickas till vyn i form av en array och där
visas.
6. Slutligen får användaren en html-sida.
Så nu är vi redo att börja. I nästa föreläsning börjar vi utveckla vårt projekt
från att skapa en katalogstruktur.
I Model-View-Controller-mönstret representerar modellen applikationsdata och tillhörande affärslogik. En modell kan representeras av ett enda objekt eller en komplex graf av relaterade objekt. I en Java-plattformsapplikation är dess data inkapslad i objekt ämnesområde, ofta utplacerad i en EJB-modul. Data överförs till och från databasen i dataöverföringsobjekt (DTO) och nås med hjälp av dataåtkomstobjekt (DAO).
En vy är en visuell representation av data som finns i en modell. En delmängd av modellen finns i en separat vy, så vyn fungerar som ett filter för modelldata. Användaren interagerar med modelldata med hjälp av den visuella visning som vyn erbjuder och kommer åt affärslogiken, som i sin tur påverkar modelldata.
Styrenheten kopplar vyn till modellen och hanterar applikationens dataflöde. Den väljer vilken vy som ska visas för användaren som svar på användarens input och enligt den affärslogik som exekveras. Styrenheten tar emot meddelandet från vyn och vidarebefordrar det till modellen. Modellen förbereder i sin tur ett svar och skickar ero tillbaka till styrenheten, där vyn väljs och ero skickas till användaren.
MVC-mönstret sträcker sig logiskt över klienten och mellanskiktet i en flerskiktsarkitektur. I Java miljö Dess modell är placerad i affärsskiktet, vanligtvis i form av en EJB-modul.
Styrenheten och vyn finns i webblagret. Vyn kommer troligen att skapas från JavaServer Faces (JSF) eller JavaServer Pages (JSP) med hjälp av ett Expression Language (EL). Styrenheten är vanligtvis en servlet som tar emot HTTP-förfrågningar från användaren.
MVC kombineras ofta med andra mönster som Command (eller Action), Strategy, Composer och " ".
Detta mönster nämndes först innan Internet skapades i dess moderna form, i en artikel publicerad i december 1979 av Trygve Reenskaug, en programmerare som då arbetade på Xeror SmallTalk.
Och även om MVC-elementen i detta mönster beskrevs för mer än 35 år sedan, motsvarar de förvånansvärt mycket deras moderna användning i webbapplikationer.
Följande bild visar en användare som gör en begäran till en styrenhet. Styrenheten behandlar begäran genom att uppdatera modellen och återge en ny vy, som sedan skickas till användaren.
MVC-mönsterdiagram
MVC-mönstret finns i många olika former. De två mest kända brukar kallas typ I och typ II.
MVC-mönstertyper:- MVC typ I. Den här typen är ett sidcentrerat tillvägagångssätt där vyn och kontrollenheten existerar som en enda enhet som kallas för view-controller. I detta tillvägagångssätt implementeras kontrollerlogiken i en vy som JSF. Alla uppgifter som utförs av styrenheten, inklusive att hämta HTTP-begäranattribut och parametrar, anropa affärslogik och hantera HTTP-sessionen, är inbyggda i vyn med hjälp av scriptlets och taggbibliotek. Typ I kopplar starkt bildandet av vyn till sekvensen av åtgärder som utförs av applikationen, vilket gör underhållet svårt.
- MVC typ II. Underhållsproblemen för typ I övervinns i typ II genom att flytta styrenhetens logik ut ur vyn och in i servleten, vilket lämnar datavisualiseringen till vyn.
Huvudskillnaden mellan typ I och typ II är platsen för styrenhetens logik: i typ I är den i vyn och i typ II är den i servleten.
Många ramverk som Spring MVC, Struts, Grails och Wicket implementerar sin egen version av MVC Type II-mönstret. Till exempel inkluderar Spring MVC konceptet med en dispatcherservlet som interagerar med HTTP-förfrågningar och utför delegering till styrenheten, och innehåller även en vy (och vyupplösare) och hanterare.
Följande figur visar ett implementeringsdiagram av MVC-mönstret under våren.
Diagram över implementeringen av MVC-mönstret under våren
Det finns miljontals webbapplikationer utspridda över hela internetvärlden. Det finns några som är ganska enkla, och det finns de som "matrisens arkitekt själv skulle bryta benet." Men de har en sak gemensamt - MVC.
Det mest populära arkitektoniska mönstret i världen bland webbapplikationer är model-view-controller ( Modellvy Controller eller bara MVC). För första gången användes det redan i slutet av 70-talet av 1900-talet, i applikationer på Smalltalk-språket. Och sedan antogs det av Java-programmerare och delas med hela världen och alla programmeringsspråk. PHP var inget undantag. Idag är det bara en liten del av programmerare som samlar in sällsynt PHP-kod som har råd att inte se mot MVC.
Det blev så populärt av en anledning. Det föddes helt enkelt för att skapa flexibla och skalbara applikationer som är lätta att underhålla och utöka.
Syftet med vår handledning är att visa enkelt exempel hur MVC-mönstret fungerar.
För att slutföra uppgifterna behöver du följande program:
Anmärkningar:
- Vi antar att du har grundläggande kunskap PHP.
Låt oss nu prata om allt i ordning. Låt oss först avslöja den stora hemligheten med förkortningen, som uppenbarligen återspeglar det faktum att applikationen kommer att bestå av tre interagerande delar:
- Modellen ansvarar för datahantering, den lagrar och hämtar de enheter som används av applikationen, vanligtvis från en databas, och innehåller logiken som implementeras i applikationen.
- Vyn ansvarar för att visa de data som lämnas av den registeransvarige. Nära relaterat till presentation är konceptet med en mall, som låter dig ändra utseendet på den information som visas. I en webbapplikation implementeras vyn ofta som en HTML-sida.
- Styrenheten kopplar ihop modellen och vyn. Den tar emot en förfrågan från klienten, analyserar dess parametrar och får åtkomst till modellen för att utföra operationer på förfrågningsdata. Redan monterade föremål kommer från modellen. De omdirigeras sedan till vyn, som skickar den genererade sidan till styrenheten, som i sin tur skickar den till klienten.
Dataflödena i denna modell kan schematiskt representeras enligt följande:
Låt oss äntligen formulera det verkliga problemet. Låt oss säga att de beordrade oss att bygga en webbplats för sociala nätverk. Denna gigantiska uppgift har en liten deluppgift: använd den befintliga databasen med vänner, se till att de ses full lista, samt detaljerad information för varje vän.
Vi kommer nu inte att överväga arkitekturen för hela det sociala nätverket. Vi tar bara en liten deluppgift, föreställer oss dess allvar och tillämpar MVC-mönstret på den.
Så fort vi börjar använda det tänker vi direkt - hur kan vi ordna skripten för vår lösning så att allt finns till hands? För att göra detta kommer vi att placera var och en av de tre sektionerna av vårt MVC-system enligt separata mappar och därmed får vi enkel struktur kataloger där det är lätt att hitta det vi behöver. Dessutom kommer vi att placera dessa tre mappar i lib-katalogen och flytta den över rotwebbkatalogen www:
/lib --/controller ---- FrendCnt.php --/model ---- Frend.php ---- FrendList.php --/view ---- frendlist.php ---- frendone.php / www -- index.php -- .htaccess
Laddar upp katalogen lib(som innehåller motorn för vår webbplats) från webbkatalogen ger oss större säkerhet, vilket gör vårt system otillgängligt för hackares lekfulla händer.
KontrollerLåt oss nu prata om allt i ordning. Låt oss börja med kontrollern, eftersom det är den första av de tre komponenterna i mönstret som möter klientförfrågan, analyserar den i element och initierar modellobjekt. Efter att modellen har bearbetat datan, accepterar den dess svar och skickar den till presentationslagret.
I vårt enkla exempel kommer kontrollern att vara koncentrerad i en enda FrendCnt-klass. Vi kommer att beskriva det mer detaljerat senare. Och nu lite om ingångspunkten till webbapplikationen - detta kommer naturligtvis att vara en fil index.php. I den kommer vi att bestämma utgångspunkten för att ansluta våra skript. Låt oss skapa en instans av kontrollern och anropa en metod på den som kommer att börja bearbeta HTTP-förfrågan och avgöra vad som ska göras härnäst.
Lista nr 1 (fil index.php):
$baseDir = dirname(__FILE__) . "/.."; include_once($baseDir . "/lib/controller/FriendCnt.php"); $controller = new FriendCnt(); $controller->invoke();
Nu om kontrollern. För oss är detta FriendCnt-klassen. Du har redan märkt att en instans av den här klassen skapas i index.php. Den har bara en invoke()-metod, som anropas direkt efter att instansen har skapats. I kontrollerkonstruktorn skapas ett objekt baserat på modellklassen - FrendList (lista över vänner) för att arbeta med data.
I invoke()-funktionen, baserat på den inkommande HTTP-förfrågan, fattas ett beslut: vilken data som krävs från modellen. Sedan anropas metoden som hämtar datan. Därefter ansluts mallar för visning, till vilka data överförs från regulatorn. Observera att kontrollern inte vet något om databasen eller hur sidan renderas.
Lista nr 2 (kontrollerfil 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 ["nyckel"])) ( $oFriendList->setKey($_GET["nyckel"]); $oFriend = $oFriendList->fetch(); inkludera $baseDir . "/lib/view/friendone.php"; ) annat ( $aFriend = $oFriendList->fetch(); inkludera $baseDir . "/lib/view/friendlist.php"; ) ) )
Modell och enheterEn modell är en bild av verkligheten, från vilken man bara tar det som behövs för att lösa ett problem. Modellen fokuserar på logiken för att lösa huvudproblemet. Många kallar denna affärslogik det bär ett stort ansvar:
- Spara, ta bort, uppdatera applikationsdata. Detta implementeras genom databasoperationer eller genom anrop till externa webbtjänster.
- Inkapsling av all applikationslogik. Absolut all applikationslogik, utan undantag, måste koncentreras i modellen. Det finns inget behov av att flytta någon del av affärslogiken till en kontroller eller vy.
Vår modell innehåller två skript, som vart och ett har sin egen klass definierad. Den centrala FriendList-klassen och Friend-enhetsklassen. I den centrala klassen sker datamanipulation: ta emot data från den registeransvarige och bearbeta den. Entitetsklassen fungerar som en behållare för överföring av data mellan modellen och vyn, och definierar även dess format. I en bra implementering av MVC-mönstret bör entitetsklasser inte refereras i styrenheten, och de bör inte innehålla någon affärslogik. Deras syfte är endast att lagra data.
I klassen FriendList, som fungerar med en lista över vänner, skapade vi en funktion som modellerar interaktionen mellan denna klass och databasen. Metoden getFriendList() returnerar en array av objekt skapade från Friend-klassen. För att underlätta arbetet med data skapades också en funktion som indexerar en rad objekt. Endast två metoder var tillgängliga för styrenheten: setKey() - ställer in nyckelfältet med vilket detaljerad data om vännen returneras; fetch() - returnerar antingen ett specifikt objekt eller hela listan med vänner.
Lista nr 3 (modellfil FriendList.php):
Require_once($baseDir . "/lib/model/Friend.php"); class FriendList ( privat $oneKey; privat funktion getFriendList() ( return array(new Friend("Alexander", "1985", " [e-postskyddad]"), ny vän("Yuri", "1987", " [e-postskyddad]"), ny vän("Alexey", "1989", " [e-postskyddad]"),); ) privat funktion getIndexedList() ( $list = array(); foreach($this->getFriendList() som $val) ( $list[$val->getKey()] = $val; ) returnera $list;) public function setKey($key) ( $this->oneKey = $key;) public function fetch() ( $aFriend = $this->getIndexedList(); return ($this->oneKey) ? $aFriend [$this->oneKey] : $aFriend;
Beroende på implementeringen av Entity-objekt kan data om det formateras som ett XML-dokument eller ett JSON-objekt.
Lista #4 (Friend.php-enhetsfil):
Klassvän ( privat $nyckel; privat $namn; privat $yearOfBirth; privat $email; offentlig funktion __construct($name, $yearOfBirth, $email) ( $this->key = md5($name . $yearOfBirth . $email) ; $this->name = $this->yearOfBirth = $email ) public function getKey() ( return $this->key; ) public function getName() >name; ) public function getYearOfBirth() ( return $this->yearOfBirth; ) public function getEmail() ( return $this->email; ) )
PrestandaNu måste vi presentera data i bästa möjliga ljus för användaren.
Det är dags att prata om presentationen. Beroende på uppgiften kan data skickas till vyn i olika format: enkla objekt, XML-dokument, JSON-objekt, etc. I vårt fall passeras ett objekt eller en array av objekt. Samtidigt oroade vi oss inte för utdata från baslagret - vad som gäller för sidfoten och sidhuvudet på den genererade sidan, denna kod upprepas i båda vyfilerna. Men för vårt lilla exempel är detta inte viktigt.
Huvudpoängen här är att visa att vyn är skild från styrenheten och modellen. I detta fall är den registeransvarige ansvarig för att överföra data från modellen till vyn.
I vårt exempel innehåller vyn bara två filer: för visning detaljerad information om en vän och för att visa en lista över vänner.
Lista nr 5 (fil för att visa listan över vänner friendlist.php):
Mina vänner
|
2024 gtavrl.ru.
|