Vad är MVC?

Så, MVC handlar om användargränssnitt(UI). Inte nödvändigtvis grafiskt röst kontroll bra också. Låt oss inte glömma att ett program kanske inte har ett användargränssnitt, men kanske har det mjukvarugränssnitt(API) eller har ingen alls och fortfarande vara användbar.

Men om vi har en användare måste det finnas ett användargränssnitt. Vad är ett gränssnitt? Detta är den sammanhängande gränsen mellan två system. I vårt fall: å ena sidan - programmet, å andra sidan - användaren. Här är de.

Programmet är helt abstrakt, vilken ämneskod som helst. Det kan göra något användbart, och användaren har behov som kan tillgodoses med hjälp av detta program. Sedan dyker det upp logikdelar som "vet" hur man, med hjälp av detta program, gör direkt vad användaren vill. Styckena är inte ämnesspecifik, ämnesspecifik logik i programmet. De är mer relevanta för användaren med dennes specifika behov, och är kombinationer av samtal och samtal till programmet.

Användningsfall

Som ett exempel, föreställ dig en terminal för handel på en börs. Terminalanvändaren skickar in en ansökan där han anger att han vill köpa 20 aktier i Svetly Put-företaget till ett pris av 1 500 rubel per aktie. Det indikerar också att ansökan är giltig i fyra timmar, och från vilket av hans konton pengarna kommer att debiteras om transaktionen lyckas.

Ett påtagligt antal attribut. En tid går, och han inser att han inte kommer att kunna köpa till detta pris och är redo att höja priset till 1 550 rubel, vilket lämnar alla andra värden. Sedan väljer han den här applikationen, klickar på "redigera"-knappen, indikerar nytt pris, Ja. Det är bekvämt.

Men på börsen kan man inte ändra en ordning i ämnesområdet finns inget sådant koncept. En ansökan kan endast lämnas in och avbrytas. För att ge användaren möjlighet att ändra en beställning med ett klick måste du komma ihåg de gamla värdena, ta bort beställningen, låta dem redigera det de kom ihåg och lägga en ny beställning. En sådan kombination. Men för användaren ser det ut som en enkel åtgärd: att ändra applikationen. Detta kallas ett användningsfall.

Låt oss komplettera vårt diagram med utrymme för användningsfall.

Användaren bör också ges möjlighet att dra dessa användningsfall och få resultat. Dessa kan vara knappar och andra grafiska element input-output, gester, taligenkänning och syntes. Alla alternativ för att utbyta data och kommandon. Voila:

Användaren drar ett av användningsfallen, vilket i sin tur manipulerar programmet. Programmet publicerar resultatet eller ändringar i dess tillstånd.

Så var är MVC egentligen?

Allt som återstår är att ge bekanta namn till de resulterande komponenterna.

När modellen publicerar ändringar bryr den sig inte om vem, den vet ingenting om View. Istället för eller tillsammans med View kan det finnas ett annat delsystem i andra änden.

Nu lite detaljer.

Det var en klassisk version av MVC - Active Model. Det händer också att modellen inte meddelar om förändringar. Sedan tar kontrollanten detta ansvar. Han vet vilka manipulationer han utför på modellen, och uppenbarligen vet han vilka förändringar i modellens tillstånd kan följa. Detta är en passiv modell.

Och ett ögonblick. Uppdelningen av kod i ämne och icke-ämne är villkorad och beror på hur pedantiskt vi vill modellera ämnesområde. Ibland är det ett rationellt beslut att ta med någon form av användningsfall i modellen. Kanske kommer detta att minska mängden kod totalt och förenkla det.

Vi tackar vår prenumerant Stanislav Ilyichev för materialet

MVC-principen webbprogrammering (Model - View - Controller, Model - View (View) - Controller) är en av de mest framgångsrika idéerna idag. MVC-principen intuitivt vid första anblicken, men inte särskilt enkelt när det grävdes in. Låt oss först titta på vad den är avsedd för.

MVC-principen, låter dig separera implementeringen av applikationslogik, utseende (GUI, GUI) och användarinteraktion.

Detta resulterar i mer strukturerad kod, tillåter mer specialiserade personer att arbeta med projektet, gör koden lättare att underhålla och gör den mer logisk och begriplig. En förändring av en komponent har minimal inverkan på de andra. Kan kopplas till en modell olika typer, olika kontroller.

Å andra sidan kräver detta större prestanda av exekveringsmaskiner, men Nyligen det är inte stort problem- Allt mer komplexa programmeringslösningar kräver support, och supportkostnaderna kommer vida överstiga kostnaderna för mer kraftfull modern utrustning.

MVC-principen Nästan alla moderna ramverk använder det.

Låt oss ta en närmare titt på komponenterna.

Modell(Modell) - innehåller den sk "affärslogik" - bearbetning och verifiering av data, åtkomst till databaser, representerar intern organisation system. Modellen ska inte interagera direkt med användaren.

Se(Visa, Visa) beskriver applikationens utseende.

Kontroller- den förbindande länken mellan modellen och vyn, tar emot data från användaren, överför den till modellen, tar emot det bearbetade resultatet och överför det till vyn.

Sambandet kan ses i diagrammet:

Bildkälla: http://www.wikipedia.org Komponentkrav:

Modeller:

• måste innehålla egenskaper som representerar specifika data;
• måste inkludera affärslogik (till exempel valideringsregler) för att säkerställa att data uppfyller kraven;
• kan innehålla kod för att arbeta med data.

Representation:

• bör i första hand innehålla uppmärkning som HTML och enkel PHP kod som används för att gå igenom, formatera och visa data;
• ska inte ha direkt tillgång till databasen. Detta är vad modeller ska göra;
• ska inte direkt komma åt $_GET , $_POST och andra variabler som erhållits från användarens begäran. Denna uppgift måste utföras av kontrollanten. Views bör endast användas för att formatera data som tas emot från kontrollanten och modellen;
• kan direkt komma åt egenskaper och metoder för styrenheten eller modellerna. Detta bör dock endast göras för datavisningsändamål.

Styrenheter:

• kan komma åt $_GET , $_POST och andra PHP-variabler, erhållen från användarens begäran;
• kan skapa och hantera modellinstanser. Till exempel, i en typisk modelluppdateringsåtgärd, kan styrenheten först skapa en instans av modellen, sedan fylla den med data från $_POST och, om modellen har sparats framgångsrikt, omdirigera användarens webbläsare till sidan för den skapade modellen. Det är värt att notera att lagring av själva modellen bör implementeras i modellklassen, inte i styrenheten;
• får inte innehålla SQL-frågor. Det är bättre att hålla dem i modeller;
• får inte innehålla HTML eller annan uppmärkning. Det är värt att lägga det i presentationen.

(Krav hämtade härifrån: http://yiiframework.ru/doc/guide/ru/basics.best-practices)

Förutom MVC-konceptet finns det många andra, till exempel FLYTTA ( M odelar, O operationer, V iews och E ventiler) - ungefär som evolution MVC(hämtat härifrån: http://habrahabr.ru/post/147038/), men dessa begrepp är mindre vanliga.

I den här artikeln kommer vi att förstå begreppet MVC och hur vi, med hjälp av ett exempel, kan tillämpa det i PHP.

MVC koncept

MVC(Model-view-controller, " Modell-View-Beteende», « Model-View-Controller") är ett applikationsdesignmönster där styrlogiken är uppdelad i tre enskilda komponenter på ett sådant sätt att modifiering av en av dem har minimal inverkan på de andra.

MVC-mallen är bra att använda när man skapar komplexa projekt där det är nödvändigt att separera arbetet hos en PHP-programmerare (eller dela upp en grupp programmerare i avdelningar), designer, layoutdesigner, etc.

MVC-mönstret separerar presentation, data och bearbetning av användarinteraktion i tre separata komponenter:

MVC-modell(Modell). Modellen tillhandahåller data (vanligtvis till vyn) och svarar även på förfrågningar (vanligtvis från kontrollanten) genom att ändra dess tillstånd.

MVC-vy(Se). Ansvarig för att visa information (användargränssnitt).

MVC-beteende(Kontroller). Tolkar användarinput och informerar modellen och vyn för att svara därefter.

För att förtydliga åtgärdsdiagrammet för MVC-mallen finns en illustration nedan.

Komponenter som presentation och beteende beror på modellen, men påverkar den inte på något sätt. En modell kan ha flera vyer. Begreppet MVC kan vara svårt att förstå, men när man väl förstår det blir det oumbärligt när man utvecklar applikationer i PHP.

MVC i PHP

En speciell egenskap när man använder MVC i PHP är att det finns en ingångspunkt till PHP-applikationen, vilket till exempel uppnås enligt följande. En index.php skapas genom vilken alla förfrågningar kommer att behandlas. För att göra detta, skapa en .htaccess-fil i mappen med indexet och placera följande kod i den:

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

I den angivna koden kontrollerar den första raden existensen av den begärda filen, och om den inte finns omdirigeras den till index.php, annars kommer även förfrågningar om webbplatsbilder att omdirigeras till indexet. Sista raden Koden konverterar förfrågningar av formen index.php?route=chat/index till formen index.php/chat/index. Om du inte har möjlighet att använda ModRewrite i din applikation, måste du göra omdirigeringen manuellt.

PHP-modell

Data om PHP-modellen finns i dess attribut och kan endast ändras genom specialfunktioner. En modell kan innehålla flera vyer. Som regel är en phpmodel en klass som fungerar med en databas, mer specifikt: skriva, läsa, radera. Naturligtvis kan läsning av information från databasen implementeras av flera vyer (funktioner). Som ett exempel, en modell av artiklar på en webbplats: du kan få en specifik artikel från databasen, en lista över de senaste, populära, någon kategori... dessa är alla representationer av modellen. För tydlighetens skull ges nedan php exempel modeller.

PHP-kontroller (beteende)

PHP-kontrollanter tar emot användarförfrågningar som vi skickat via index.php, och i enlighet med dem, justerar driften av modellen. Det vore mer korrekt att säga att de kontrollerar arbetet php-applikationer.

PHP representation

Vyn övervakar förändringar i modellen och skapar eller ändrar gränssnittet för php-applikationen.

Lista över data

förnamn ?>

efternamn?>

Hur fungerar detta?PHPMVC-mall?

När användaren kommer åt den önskade webbadressen väljs motsvarande styrenhet, som kommer åt vyn och modellen, och information visas. Styrenheten i mvc är med andra ord den sammanbindande länken mellan modellen och vyn.

Fördelar med MVC mall när skapa PHP applikationer

Som nämnts ovan är detta först och främst differentieringen av PHP-webbplatsutvecklare till avdelningar. Hastigheten ökar också php fungerar applikationer, om de har skapats större projekt. Tja, det som bekymrar PHP-utvecklaren själv är den korrekta struktureringen php-kod(allt är på sin plats, det är lättare att förstå).

MVC exempel

Vi kommer inte att fokusera för mycket på exemplet på hur MVC fungerar, eftersom vi redan har ett, lägger jag bara till ett par diagram till för en djupare förståelse.

Ett annat schema för hur en MVC-mall fungerar i PHP, det är mer än lätt att förstå.

Konceptet MVC (Model-View-Controller) nämns mycket ofta i webbprogrammeringsvärlden i senaste åren. Alla som på något sätt är kopplade till webbapplikationsutveckling har stött på denna akronym på ett eller annat sätt. Idag kommer vi att förstå vad MVC-konceptet är och varför det blev populärt.

Antik historia

MVC är inte ett projektmönster, det är ett designmönster som beskriver hur man bygger strukturen för vår applikation, ansvaret och samspelet mellan var och en av delarna i denna struktur.

Det beskrevs första gången 1979, naturligtvis, för en annan miljö. Det fanns inget koncept med en webbapplikation då. Tim Berners Lee sådde fröna World Wide Webben (WWW) dök upp i början av nittiotalet och förändrade världen för alltid. Mallen vi använder idag är en anpassning original mall till webbutveckling.

Den vilda populariteten för denna struktur i webbapplikationer berodde på att den ingick i två utvecklingsmiljöer som blev mycket populära: Struts och Ruby on Rails. Dessa två utvecklingsmiljöer satte vägen för hundratals utvecklingsmiljöer som skapades senare.

MVC för webbapplikationer

Tanken bakom MVC-designmönstret är mycket enkel: det måste finnas en tydlig ansvarsfördelning för olika funktion i våra applikationer:

Ansökan är uppdelad i tre huvudkomponenter som var och en ansvarar för olika uppgifter. Låt oss titta på komponenterna i detalj med hjälp av ett exempel.

Kontroller

Kontroller hanterar användarförfrågningar (mottagna som HTTP GET- eller POST-förfrågningar när användaren klickar på gränssnittselement för att utföra olika åtgärder). Dess huvudsakliga funktion är att anropa och koordinera åtgärden av de nödvändiga resurserna och objekten som behövs för att utföra åtgärder som specificeras av användaren. Normalt anropar styrenheten lämplig modell för uppgiften och väljer passande utseende.

Modell

Modell– Det är de data och regler som används för att arbeta med data som representerar konceptet att hantera applikationen. I alla applikationer modelleras hela strukturen som data som bearbetas på ett visst sätt. Vad är en användare för en applikation - ett meddelande eller en bok? Endast data som måste behandlas enligt regler (datum kan inte peka in i framtiden, e-post måste vara i ett visst format, namn får inte vara längre än X tecken, och så vidare).

Modellen ger styrenheten en representation av de data som användaren har begärt (meddelande, boksida, fotoalbum, etc.). Datamodellen kommer att vara densamma oavsett hur vi vill presentera den för användaren. Därför väljer vi valfri tillgänglig vy för att visa data.

Modellen innehåller det mesta viktig del logiken i vår applikation, logiken som löser problemet vi har att göra med (forum, butik, bank, etc.). Styrenheten innehåller i princip den organisatoriska logiken för själva applikationen (ungefär som hushållning).

Se

Se tillhandahåller olika sätt representationer av data som erhålls från modellen. Det kan vara en mall som är fylld med data. Det kan finnas flera olika typer och regulatorn väljer vilken som passar det bästa sättet för den aktuella situationen.

En webbapplikation består vanligtvis av en uppsättning kontroller, modeller och vyer. Styrenheten kan utformas som en huvudstyrenhet som tar emot alla förfrågningar och anropar andra styrenheter för att utföra åtgärder beroende på situationen.

Låt oss titta på ett exempel

Låt oss säga att vi måste utveckla en onlinebokhandel. Användaren kan utföra följande åtgärder: se böcker, registrera, köp, lägg till objekt i den aktuella beställningen, skapa eller ta bort böcker (om han är administratör). Låt oss se vad som händer när en användare klickar på en kategori fantasi för att se titlarna på böcker som finns tillgängliga i vår butik.

Vi har en specifik kontroller för att hantera alla åtgärder relaterade till böcker (visa, redigera, skapa, etc.). Låt oss kalla det books_controller.php i vårt exempel. Vi behöver också en modell som book_model.php, som behandlar data och logik som är associerade med en butiksartikel. Sammanfattningsvis behöver vi flera vyer för att representera data, till exempel en boklista, en redigeringssida och så vidare.

Följande bild visar hur en användares begäran om att se en lista med böcker om ett ämne behandlas fantasi:

Styrenheten (books_controller.php) tar emot användarförfrågan ( HTTP-förfrågan GET eller POST). Vi kan skapa en central styrenhet, till exempel index.php, som tar emot begäran och anropar books_controller.php.

Styrenheten kontrollerar begäran och parametrarna och anropar sedan modellen(book_model.php), frågar hon har en lista över tillgängliga böcker om ämnet fantasi .

Modellen tar emot data från databasen (eller annan källa som lagrar information), tillämpar filter och nödvändig logik och returnerar sedan data som representerar en lista med böcker.

Kontrollanten använder lämplig vy för att presentera data för användaren. Om förfrågan kommer med mobiltelefon, mobiltelefonvy används; om användaren använder en viss gränssnittsdesign, väljs motsvarande vy, och så vidare.

Vad är fördelarna?

Mest uppenbar fördel Det vi får ut av att använda MVC-konceptet är en tydlig åtskillnad mellan presentationslogik (användargränssnitt) och applikationslogik.

Stöder olika typer av användare som använder Olika typer enheter är vanligt problem våra dagar. Gränssnittet som tillhandahålls bör vara annorlunda om begäran kommer med personlig dator eller från en mobiltelefon. Modellen returnerar samma data, den enda skillnaden är att regulatorn väljer olika sorter att mata ut data.

Förutom att isolera vyer från applikationslogik, minskar MVC-konceptet avsevärt komplexiteten stora applikationer. Koden visar sig vara mycket mer strukturerad, och gör det därmed lättare att supporta, testa och återanvändning beslut.

Varför använda arbetsmiljön?

När du använder arbetsbänken är den grundläggande MVC-strukturen redan förberedd och allt du behöver göra är att utöka strukturen genom att placera dina filer i lämpliga kataloger för att matcha MVC-mönstret. Dessutom kommer du att ha en uppsättning funktioner som redan är skrivna och väl testade.

Låt oss ta cakePHP som ett exempel arbetsmiljö MVC. Efter installationen har du tre huvudkataloger:

• kaka/
• försäljare/

Mapp appär där dina filer finns. Det här är platsen för att utveckla din del av applikationen.

I mapp kaka cakePHP-filer (workbench-funktionalitet) är värd.

Mapp försäljare tjänar till förvaring PHP-bibliotek tredjepartsutvecklare.

Din arbetsyta (appkatalog) har följande struktur:

• app/
  • config/
  • kontroller/
  • plats/
  • modeller/
  • plugins/
  • tester/
  • försäljare/
  • visningar/
  • webroot/

Du måste placera dina kontroller i en katalog kontroller, modeller i katalogen modeller och skriver i katalogen vyer!

När du börjar använda arbetsbänken kommer det omedelbart att bli tydligt var praktiskt taget varje del av din applikation som behöver skapas eller modifieras finns. Denna organisation i sig förenklar avsevärt processen att utveckla och underhålla en applikation.

Använda arbetsbänken för vårt exempel

Eftersom den här handledningen inte är avsedd att visa processen att skapa en applikation med cakePHP, kommer vi bara att visa koden för modellen, styrenheten och vyn med kommentarer om fördelarna med att använda MVC-arbetsbänken. Koden är medvetet förenklad och olämplig för användning i en riktig applikation.

Kom ihåg att vi tittade på en bokhandel och en nyfiken användare som ville se full lista böcker om ämnet fantasi. Kontrollanten tog emot användarens begäran och samordnade nödvändiga åtgärder.

Så fort användaren klickar på knappen begär webbläsaren den angivna webbadressen:

www.ourstore.com/books/list/fantasy

CakePHP formaterar URL med hjälp av ett mönster /controller/action/param1/param2, Var handlingär en funktion som anropas av styrenheten. I det gamla klassiskt utseende url kommer att se ut så här:

www.ourstore.com/books_controller.php?action=list&category=fantasy

Kontroller

I cakePHP-arbetsmiljön kommer vår styrenhet att se ut så här:

class BooksController utökar AppController (

Funktionslista($category) (

$this->set("böcker", $this->Book->findAllByCategory($category));

Funktion add() ( ... ... )

Funktion delete() ( ... ... )

... ... } ?>

Enkelt, eller hur? Denna kontroller kommer att sparas som books_controller.php och postat i /app/kontroller. Den innehåller en lista över funktioner som utför åtgärderna för vårt exempel, såväl som andra funktioner för att utföra bokrelaterade operationer (lägg till en ny bok, ta bort en bok och så vidare).

Arbetsmiljön ger oss många färdiga lösningar och vi behöver bara skapa en lista med böcker. Det finns en basklass som redan definierar styrenhetens grundläggande funktionalitet, så du måste ärva egenskaperna och funktionerna för denna klass ( AppControllerär arvtagaren Kontroller).

Allt du behöver göra i åtgärdslistan är att ringa modellen för att få data och sedan välja en vy för att presentera den för användaren. Så här går det till.

denna-> Bok- det här är vår modell och en del av koden:

$this->Book->findAllByCategory($category)

ber modellen att returnera en lista med böcker om det valda ämnet (vi ska titta på modellen senare).

Metod uppsättning i kö:

$this->set("böcker", $this->Book->findAllByCategory($category));

Styrenheten skickar data till vyn. Variabel böcker accepterar data som returneras av modellen och gör den tillgänglig för vyn.

Nu återstår bara att visa vyn, men denna funktion görs automatiskt i cakePHP om vi använder standardvyn. Om vi ​​vill använda en annan typ måste vi uttryckligen anropa metoden framställa.

Modell

Modellen är ännu enklare:

klassbok utökar AppModel (

Varför är det tomt? Eftersom den ärver från en basklass som ger den funktionalitet som krävs och vi måste använda CakePHPs namnkonvention för att körtiden ska hantera alla andra uppgifter automatiskt. Till exempel, cakePHP vet baserat på namnet som den här modellen Använd i BooksController, och att den har tillgång till en databastabell med namnet böcker.

Med denna definition kommer vi att ha en modell som bara kan läsa, radera eller lagra data i databasen.

Spara koden som book.php i mappen /app/modeller.

Se

Allt vi behöver göra nu är att skapa en vy (av minst, en) för en lista över åtgärder. Vyn kommer att ha HTML-kod och några få (så få som möjligt) rader PHP-kod för att gå igenom den mängd böcker som modellen tillhandahåller.

namn	Författare	Pris

Som du kan se skapar vyn inte en hel sida, utan bara ett fragment av HTML (en tabell i I detta fall). Eftersom CakePHP tillhandahåller ett annat sätt att definiera en sidmall, och vyn infogas i den mallen. Arbetsbänken förser oss också med några hjälpobjekt för att utföra vanliga uppgifter när vi skapar delar HTML-sidor(infoga formulär, länkar, Ajax eller JavaScript).

Spara vyn som list.ctp(listan är åtgärdens namn och ctp betyder CakePHP-mall) i mappen /app/views/books(eftersom det är en vy för en kontrollåtgärd).

Så här exekveras alla tre komponenterna med hjälp av CakePHP-arbetsbänken!

Applikationsutveckling enligt mallen MVC design(model-view-controller) är typiskt för Java och, när det appliceras på DroidScript, verkar det obegripligt och onödigt. Varför komplicera allt? MVC fick en aura av komplexitet och "magi" på grund av användningen av vackra men obegripliga ord (koncept, modell, affärslogik, mönster) och komplexa demonstrationer i Java-sammanhang när man övervägde det. Allt är mycket enklare: MVC är ett av designmönstren som producerar ytterligarekoddelning i objektorienterad miljö.

Det centrala elementet i MVC-modellen är styrenheten - normal tillämpning DroidScript, från vilket koden relaterad till visuell markering och utseende av widgets, samt data och metoder för att komma åt dem, härleds. Genom data är vi vana vid att förstå information som lagras i arrayer, filer och databaser. Men i MVC-konceptet förstås data i ordets breda bemärkelse - det här är allt som inte är applikationskod:

• extern data från filer och databaser - metadata, text, grafik, ljud, musik, etc.
• intern applikationsdata - rader med etiketter på knappar och andra kontroller, text in dialogrutor, beskrivning av stilar, konstanter, programvara genererad grafik, etc.

Ur användarens synvinkel förändras inte hans erfarenhet av applikationen när han använder MVC: han klickar också på knappar, väljer data och hur den visas. Förändringar kan beröra anläggningar detta jobb. Och på utvecklingssidan är förändringarna märkbara: interaktionen mellan data och dess visning i MVC-konceptet sker genom kontrollenheten och under dess kontroll.

Låt oss först titta på ett enkelt exempel på hur man använder MVC i en enfilsapplikation.

Enfilsimplementering av MVC-modellen

Låt oss ta en enkel applikation.

Funktion OnStart())( var _lay = app.CreateLayout("linjär", "VCenter,FillXY"); var _btnShowVersion = app.CreateButton("Visa version", 0.3, 0.1); _btnShowVersion.SetBackColor("#667789") ; _btnShowVersion.SetMargins(0, 0.05, 0, 0));

Vid första anblicken verkar allt bra, men anta att du behöver förändras färgschema applikationer och visa text på flera språk. Detta kommer att leda till komplikationer, eftersom all data i exemplet som visas är fasta värden (bokstaver). Detta minskar kodens flexibilitet avsevärt och komplicerar dess felsökning och support.

En annan nackdel är att data - etiketterna på knappen, markeringen - metoder för att visa widgets och åtgärden - kodblocket som ändrar etiketten på knappen när den klickas finns i ett block och i en fil. Det vill säga, för att ändra etiketten måste du öppna den här filen och få tillgång till hela applikationskoden. Det är som att byta ett bildäck kräver att man demonterar bilens kaross för att få tillgång till allt innehåll. För vad? Under processen att demontera bilkroppen kan du av misstag fånga något och göra det ur funktion. Det är också möjligt i koden: Jag ville byta ut radnamnet på ett ställe, men ersättningen skedde genom hela filen, vilket ledde till en spridning av fel. Eller så ville du bara ändra färgen på knappen, men av misstag fångade koden i närheten och hela applikationen slutade fungera.

En av uppgifterna för MVC-mönstret är just att skilja åtkomst: först identifieras modulen (eller kodblocket) som är källan till felet, och sedan ges åtkomst endast till den. Varför ge tillgång till elektronik och motor i en bil om du behöver byta däck?

Om utvecklingen utförs i en fil, händer det ofta så här: nya funktioner placeras på plats, i början eller slutet av koden, vilket med tiden leder till att de blandas. Låt oss lägga till blandningen av kod i själva funktionerna här, och om en månad även med kommentarer kommer det att vara svårt att förstå allt detta.

Låt oss implementera exemplet som visas ovan i MVC-sammanhang. För att göra detta måste all kod delas upp och grupperas i lämpliga block. Ordningen på blocken i koden är inte viktig, men det är bättre att hålla sig till logiken: för att styrenheten ska fungera är både data och element för att visa dem nödvändiga, så det placeras sist. När data visas måste den finnas. Det betyder att modellblocket kommer först:

1. Modell
2. Prestanda
3. Kontroller

//+++ modell (function())( var _obj = ; //+++ data var _version = "Applikationsversion 1.0"; var _titleShowVersion = "Visa version"; // --- data
//+++ offentliga metoder för att komma åt data _obj.getVersion = function())( return _version; ) _obj.btnGetTitle = function())( return _titleShowVersion; ) // --- öppen metoder för att komma åt data window.model = _obj; // öppen åtkomst till det lokala objektet ))(); //--- modell //+++ presentation (funktion ()( var _lay = app.CreateLayout("linear", "VCenter,FillXY"); var _btnShowVersion = app.CreateButton(window.model.btnGetTitle(), 0.3, 0.1); _btnShowVersion.name = "_btnShowVersion.SetBackColor("#66778976");

))(); //--- presentation //+++ controller (function(p_object)( var _obj = ; // public object search method _obj.findObjectById = function(p_name)( var _objectList = app.GetObjects(); för (var _i i _objectList)( if(_objectList[_i].name == p_name)( return _objectList[ _i]; ) ) return null; function OnStart())( var _buttonShowVersion = window.control.findObjectById("_btnShowVersion"); //+++ action _buttonShowVersion.SetOnTouch(function())( this.SetText(window.model.getVersion()); )) ; / / --- action ) //--- controller

På grund av separeringen av funktioner har applikationskoden ökat flera gånger.

Inledningsvis görs alla variabler privata och först i slutet, om nödvändigt, görs åtkomst till dem genom det globala fönsterobjektet, vilket låter dig klara dig utan globala variabler.

Exemplet implementerar en widgetsökning, som i Java, men du kan göra det enklare och effektivisera koden genom att öppna åtkomst till objektet via den globala associativ array:

Window.controls = ;
window.controls.buttonShowVersion = _btnShowVersion;

Datan, dess visning och reaktion på åtgärder finns i olika block, utan att blandas med varandra, vilket gör att utvecklaren lättare kan arbeta med dem. Ju enklare det är att arbeta med data och kod, desto färre fel blir det, desto lättare blir det att felsöka, stödja och skala.

Det är inte nödvändigt att separera alla dessa tre komponenter från varandra. Det finns flera varianter av MVC, såväl som ofullständiga implementeringar av denna modell. Du kan till exempel separera data och kombinera åtgärdskoden med kontrollerna med hjälp av anonyma återuppringningsfunktioner.

När man arbetar i en objektorienterad miljö finns separationen av kod och data redan från början: data och åtgärder grupperas i klasser, objekt interagerar med varandra genom offentliga metoder, etc. MVC möjliggör en finare, mer explicit separation av kod och data i deras kärnfunktioner.

För att bättre förstå fördelarna med att använda MVC-modellen, låt oss titta på att dela upp koden i separata filer.

Trefilsimplementering av MVC-modellen

Kod division efter olika filer används till mer bekvämt arbete med honom. Stor mängd De små filerna du ser i MVC-projekt kan ifrågasätta detta uttalande, men att se filerna är en sak, att arbeta med dem är en annan. Vid varje ögonblick interagerar utvecklaren med en fil från en liten uppsättning av dem. För att göra detta behöver du ha en god förståelse för projektorganisationens struktur och ständigt övervaka tre filer- modell, vy och kontroller, för att inte redigera av misstag tredje parts kod. På grund av DroidScript-redigerarens begränsningar är sådan gruppering endast möjlig med filnamn i rotkatalogen, till exempel:

myproject_model.js - modell
myproject_view.js - visa
myproject_control.js - styrenhet

Nedan är ett exempel på att dela upp koden från föregående exempel i filer.

myproject_model.js - modell(function())( var _obj = ; //+++ data var _version = "Applikationsversion 1.0"; //--- data //+++ strängresurs var _titleShowVersion = "Visa version"; //++ + strängresurs _obj.getVersion = function() (retur _version; ) _obj.btnGetTitle = function() (retur _titleShowVersion; ) window.model = _obj ))(); myproject_view.js - visa(function ()( var _lay = app.CreateLayout("linear", "VCenter,FillXY"); var _btnShowVersion = app.CreateButton(window.model.btnGetTitle(), 0.3, 0.1); _btnShowVersion.name = "_btnShowVersion" ; _btnShowVersion.SetBackColor("#66778976"); myproject_control.js - styrenhet app.LoadScript("mittprojekt_modell.js"); app.LoadScript("mittprojekt_vy.js");(function(p_object)( var _obj = ; // objektsökningsmetod _obj.findObjectById = function(p_name)( var _objectList = app.GetObjects(); för (var _i i _objectList)( if(_objectList[_i].name = = p_name)( return _objectList[ _i]; ) ) return null; function OnStart())( var _buttonShowVersion = window.control.findObjectById("_btnShowVersion"); //+++ action _buttonShowVersion.SetOnTouch(function())( this.SetText(window.model.getVersion()); )) ; / / --- action )

Denna enkla uppdelning av kod i filer var inte lätt. För att göra detta upprättades en koppling med modellen i förväg genom den allmänna egendomen för det globala rotobjektet - fönster.modell, och kopplingen till vyn sker genom en global array _Karta genom metoden app.GetObjects.

Fördelen med att dela upp koden i filer är att man nu kan ersätta koden som ett helt block, till exempel för Snabbstart genomföra projektet enkel modell, och ersätt sedan filen med en annan mer funktionell, men med samma namn och gränssnitt. Detta tillvägagångssätt används till exempel vid reparation av utrustning. Om tidigare reparationer bestod av en långsam och mödosam sökning och byte av trasiga radiokomponenter, byts nu standardenheter ut. Kostnaden för att reparera en komplex skiva är betydligt högre än dess snabba utbyte.

Det följer av ovanstående att ett väldesignat gränssnitt avsevärt kan förenkla den efterföljande integrationen av moduler.

I JavaScript-objekt passeras genom referens. Om du ändrar widgetegenskaperna i kontrollern ändras egenskaperna han själv widget. Teoretiskt är det möjligt att separera vyobjekt från kodobjekt, som man gör i Java, där xml-strukturer används som det första, men det finns ingen mening med detta av två skäl - frånvaro i DroidScript visuell redaktör gränssnitt och en begränsad uppsättning tillgängliga egenskaper för API-objekt.

Multi-fil implementering av MVC-modellen

Beroende på de tilldelade uppgifterna och projektets komplexitet kan detaljerna för separationen av kod och data i allmänhet vara olika. Du kan ytterligare separera användardata från resurser, du kan borra ner i resurser efter typ, gruppåtgärder, etc. Men DroidScript-redigeraren tillåter dig inte att arbeta fullt funktionellt med MVC.