Në këtë artikull do të shkruajmë "skeletin" e projektit tonë. Me fjalën "kornizë" nënkuptoj kodin e punës që do të bazohet në qasjen MVC, domethënë do të ketë një ndarje të qartë të logjikës në kontrollues, veprime, shabllone (pamje) dhe modele.

Dhe kështu le të fillojmë, siç kam shkruar tashmë në artikullin e mëparshëm, modeli MVC nënkupton një pikë hyrje - index.php, të gjitha kërkesat do të kalojnë përmes këtij skenari, e gjithë logjika e projektit do të funksionojë përmes tij. Për të zbatuar këtë qasje, ju duhet të konfiguroni serverin, supozohet se faqja funksionon në një server apache, kështu që ne vetëm duhet të krijojmë një skedar .htaccess, në të cilin do të specifikojmë rregullat e rrugëzimit të URL-së. Përveç përcaktimit të pikës hyrëse, rutimi ju lejon të krijoni CNC (URL të lexueshme nga njeriu). Kjo do të thotë, pas cilësimeve të sakta, adresat e faqeve do të duken si kjo faqe.ru/article/new.
Së pari, le të krijojmë një .htaccess që do të ridrejtojë përpunimin e të gjitha faqeve në skriptin index.php. Kodi duket si ky:

RewriteEngine në RewriteCond% (REQUEST_FILENAME)! -F RewriteCond% (REQUEST_FILENAME)! -D RewriteRule ^ (. *) $ Index.php?Rruga = 1 $

Skedari .htaccess duhet të gjendet në dosjen rrënjë të faqes dhe menjëherë duhet të krijohet skripti index.php, i cili është pika hyrëse. Le të vendosim një rresht në index.php për të provuar nëse ridrejtimi funksionon:

Echo "test";

Tani mund të kontrolloni nëse ridrejtimi funksionon, futni ndonjë adresë dhe shihni se çfarë ndodh: test-mvc.web / sdf / sdf / ose test-mvc.web / sdf / sdf / 2342 / nuk ka rëndësi, në çdo rast, "Test". Nëse e keni parë këtë mbishkrim, do të thotë se kemi pasur sukses.
Le të vazhdojmë, për lehtësi, le të krijojmë një skedar config.php në rrënjën e faqes, në të cilin do të vendosim konstante të ndryshme që e bëjnë më të lehtë personalizimin e faqes. Këto mund të jenë shtigje të ndryshme drejt skripteve, aksesi në bazën e të dhënave, etj. Tani në konfigurim le të vendosim sa vijon:

// Vendos konstante: define ("DS", DIRECTORY_SEPARATOR); // ndarës për shtigjet e skedarëve $ sitePath = rrugë reale (diremri (__ FILE__). DS); define ("SITE_PATH", $sitePath); // shteg për në dosjen rrënjë të faqes // për t'u lidhur me bazën e të dhënave define ("DB_USER", "root"); define ("DB_PASS", ""); define ("DB_HOST", "localhost"); define ("DB_NAME", "blog_mvc");

Në mënyrë që konstantet dhe të dhënat e tjera të konfigurimit të përdoren gjatë gjithë projektit, është e nevojshme të përfshihet skripti config.php në skedarin index.php.
Përveç lidhjes së skedarit me cilësimet, në index.php ju duhet të krijoni një lidhje me bazën e të dhënave, të lidhni një skript me bërthamën e faqes dhe të filloni një ruter në të cilin do të bëhet rutimi.
Tani, me radhë, krijimi i një lidhjeje me bazën e të dhënave do të jetë në index.php në mënyrë që lidhja të hapet vetëm një herë. Pasi të kemi hapur lidhjen një herë, ne mund ta përdorim atë në të gjithë kontrollorët dhe modelet, por më shumë për këtë më vonë. Tani për tani, le të krijojmë një lidhje me bazën. Për të punuar me bazën e të dhënave, vendosa të përdor PDO. Mund të lexoni më shumë rreth PDO.
Ne do të vendosim thelbin e faqes në dosjen kryesore dhe do të emërtojmë skriptin core.php, këtu do të shkruajmë një funksion që do të lidhet vetë, klasat janë të nevojshme për punën. Një funksion i tillë do të lehtësojë dhe thjeshtojë shumë punën tonë me kontrollorët, modelet, etj. Sepse, duke parë përpara, do të them se çdo kontrollues dhe çdo model do të jetë një klasë më vete.
Përveç klasave të lidhjes automatike, ne do të shtojmë një depo (regjistër) në thelbin e krijimit të një depoje, në të cilën do të ruajmë të gjitha objektet dhe variablat e nevojshëm që mund të jenë të dobishëm kudo në projekt.
Ne gjithashtu lidhim ruterin në skedarin e indeksit, ai do të analizojë URL-në dhe do të lidhë kontrolluesin dhe veprimin e nevojshëm. Unë shkrova se çfarë është një kontrollues në artikullin e mëparshëm, por qëllimisht e kapërceva informacionin për veprimin, pa u mbingarkuar me informacione të panevojshme. Pra, çfarë është veprimi?
Një kontrollues është një klasë që përmban metoda të ndryshme, me qasjen MVC, secila metodë do të jetë një veprim. Kjo do të thotë, një veprim është një metodë e klasës që do të përpunojë të dhënat dhe do t'i kalojë ato në pamje (te shabllon). Mund të mos jetë ende plotësisht e qartë, por pas shembullit gjithçka do të bjerë në vend.
Në këtë fazë mjafton teoria, le të kalojmë në praktikë. Unë do të jap kodin e skedarëve, punën e të cilave, e përshkrova më lart.
Kodi i skriptit Index.php:

// aktivizoni shfaqjen e të gjitha gabimeve error_raporting (E_ALL); // përfshijnë konfigurimin e përfshirjes ("/config.php"); // Lidhu me bazën e të dhënave $ dbObject = PDO e re ("mysql: host =". DB_HOST. "; Dbname =". DB_NAME, DB_USER, DB_PASS); // përfshijnë thelbin e faqes përfshijnë (SITE_PATH. DS. "core". DS. "core.php"); // Ngarko ruterin $ router = router i ri ($ regjistri); // shkruani të dhënat në regjistër $ registry-> set ("ruteri", $ router); // vendosni shtegun për në dosjen e kontrollorëve. $ router-> setPath (SITE_PATH. "kontrolluesit"); // nis ruterin $ router-> start ();

Skripti Core.php:

// Ngarkoni klasat në funksionin e fluturimit __autoload ($ className) ($ filename = strtolower ($ className). ".Php"; // përcaktoni klasën dhe gjeni shtegun për të $ expArr = shpërthejë ("_", $ className ) ; if (bosh ($ expArr) OSE $ expArr == "Baza") ($ folder = "klasat";) other (çelës (strtolower ($ expArr)) (rasti "kontrollues": $ folder = "kontrolluesit"; break ; case "model": $ folder = "models"; break; default: $ folder = "classes"; break;)) // shtegu i klasës $ file = SITE_PATH. dosje $. DS. $ emri i skedarit; // kontrollo për skedarin e disponueshmërisë nëse (skedari_ekziston (skedari $) == false) (kthimi false;) // përfshi skedarin me klasën përfshin (skedar $);) // filloni regjistrin (ruajtjen) $ regjistri = regjistri i ri;

Klasa e depove Registry.php do të vendoset në dosjen / classes /

( Përjashtim ("Nuk mund të caktohet var" ". Çelësi $." `. Tashmë i caktuar.");) $ This-> vars [$ key] = $ var; kthe e vërtetë;) // merr funksionin e të dhënave merr (kyç $) (nëse (isset ($ this-> vars [$ key]) == false) (return null;) kthe $ this-> vars [$ key];) // hiqni funksionin e të dhënave hiq ($ var) (i pacaktuar ($ this-> vars [kyç $]);))

Kodi për skedarin router.php, i cili ndodhet në dosjen / klasa /

// klasa e ruterit Klasa Router (regjistri $ privat; shtegu privat i $; privat $ args = grup (); // merrni funksionin e ruajtjes __construct ($ regjistri) ($ this-> regjistri = $ regjistri;) // vendos shtegu i dosjes me funksionin e kontrolluesve setPath (shtegu $) (shtegu $ = shkurtimi (shtegu i $, "/ \\"); shtegu i $. = DS; // nëse shtegu nuk ekziston, sinjalizoni nëse (is_dir ( $ path) == false ) (hedh një përjashtim të ri ("Rruga e pavlefshme e kontrolluesit:` ". $ shteg." '");) $ this-> path = $ path;) // përcaktimi i kontrolluesit dhe veprimi nga funksioni privat url getController (& skedari $, & kontrolluesi $, & veprimi $, & $ args) ($ route = (bosh ($ _ GET ["rrugë"]))? "": $ _GET ["rrugë"]; e pacaktuar ($ _ GET ["rrugë"]); nëse (bosh ($ itinerari)) ($ itiner = "indeks";) // Merrni pjesë të url-së $ route = shkurtoni ($ route, "/ \\"); $ pjesë = shpërthejnë ("/", $ route); // Gjeni kontrolluesin $ cmd_path = $ this-> shteg; foreach ($ pjesë si pjesë $) ($ fullpath = $ cmd_path. $ Part; // Kontrolloni nëse dosja ekziston nëse (është_dir ($ rrugë e plotë)) ($ cmd_rruga. = $ pjesa DS; shift_array ($ pjesë); vazhdo; ) // Gjeni skedarin if (is_file ($ fullpath. ". Php")) ($ controller = $ part; array_shift ($ part); break;)) // nëse url nuk specifikon një kontrollues, atëherë përdorni indeksi i paracaktuar nëse (i zbrazët ($ kontrollues)) ($ kontrollues = "indeks";) // Merrni veprimin $ action = shift_array ($ pjesë); nëse (bosh (veprim $)) ($ veprim = "indeks";) skedari $ = $ cmd_rruga. kontrollues $. ".php"; $ args = $ pjesë; ) funksioni start () (// Analizoni shtegun $ this-> getController ($ file, $ controller, $ action, $ args); // Kontrolloni nëse skedari ekziston, përndryshe 404 nëse (is_readable ($ file) == false ) (die ("404 Nuk u gjet");) // Përfshi skedarin përfshin ($ file); // Krijo një shembull të kontrolluesit $ class = "Controller_". $ Controller; $ controller = i ri $ class ($ this -> regjistri); // Nëse veprimi nuk ekziston - 404 nëse (is_callable (array ($ kontrollues, $ veprim)) == false) (die ("404 Nuk u gjet");) // Ekzekutoni veprimin $ kontrollues -> veprim $ ();))

Tani duhet të krijojmë dosje për ruajtjen e kontrollorëve, shablloneve dhe modeleve - në rrënjë do të krijojmë tre kontrollues dosjesh, pamje dhe modele. Dhe le të krijojmë disa skedarë testimi /controllers/index.php, /views/index/index.php dhe /models/model_users.php dhe tani plotësojmë skedarët:
Për kontrolluesin:

// kontrolluesi Klasa Controller_Index Zgjat Controller_Base (// shabllon publik $ layouts = "first_layouts"; // indeksi i funksionit të veprimit () ($ model = Model_Users të rinj (); $ userInfo = $ model-> getUser (); $ this-> template-> vars ("userInfo", $ userInfo); $ this-> template-> view ("indeks");))

Për shfaqje (/views/index/index.php)

Pamje testuese
ID:
emri:

Dhe modeli:

// Modeli Klasa Model_Users (funksioni publik getUser () (array i kthimit ("id" => 1, "emri" => "emri_testit");))

Siç mund ta keni vënë re, klasa e kontrolluesit trashëgon nga klasa mëmë Controller_Base. Kjo është bërë për të thjeshtuar klasën e kontrolluesit. Meqenëse ende na duhet të lidhim klasën për të punuar me shabllone, lidhja e saj zhvendoset në Controller_Base.
Unë do të jap kodin e tij, ai ndodhet në dosjen / classes / dhe quhet controller_base.php:

// Klasa e kontrolluesit abstrakt Klasa Abstract Controller_Base (regjistri i mbrojtur $; shabllon i mbrojtur i $; paraqitjet e mbrojtura të $; // shabllon publik $ vars = grup (); // përfshin shabllonet në funksionin e konstruktorit __construct ($ regjistri) ($ this-> regjistri = regjistri $; // shabllonet $ this-> shabllon = model i ri ($ this-> paraqitjet, get_class ($ this));) indeksi i funksionit abstrakt ();)

Tani gjithçka që mbetet është të merremi me shabllonet. Në klasën abstrakte Controller_Base, ne e quajmë klasën Template dhe i kalojmë asaj emrin e shabllonit dhe emrin e kontrolluesit.
Kodi i klasës Template, i cili ndodhet këtu / klasa / dhe quhet template.php

// klasë për lidhjen e shablloneve dhe kalimin e të dhënave në ekran Shablloni i klasës (shabllon $ privat; kontrollues privat $; paraqitje $ private; $ vars private = grup (); funksioni __construct ($ paraqitjet, $ controllerName) ($ this-> paraqitjet = paraqitjet $; $ arr = shpërthejnë ("_", $ controllerName); $ this-> kontrollues = strtolower ($ arr);) // vendosja e variablave për të shfaqur vars funksionet ($ varname, $ vlera) (if (isset ( $ this-> vars [$ varname]) == true) (trigger_error ("Nuk mund të vendoset var" ". $ varname." ". Është vendosur tashmë dhe nuk lejohet mbishkrimi.", E_USER_NOTICE); kthe false;) $ this -> vars [$ varname] = $ vlerë; kthe e vërtetë;) // shfaq pamjen e funksionit ($ emri) ($ pathLayout = SITE_PATH. "views". DS. "layouts". DS. $ this-> layouts. ". php "; $ contentPage = SITE_PATH." shikime ". DS. $ this-> kontrollues. DS. $ name." .php "; if (file_exists ($ pathLayout) == false) (trigger_error (" Layout `". $ faqosjet this->. "'nuk ekziston.", E_USER_NOTICE); kthe false;) nëse (skedari_ekziston ($ contentPage) == e rreme) (gabim_shkaku ("Stemplate" ". emri $. "` nuk ekziston. ", E_USER_NOTICE); kthej false; ) foreach ($ this-> vars si $ key => $ vlera) ($$ key = $ vlera;) përfshijnë ($ pathLayout); ))

Nëse e lexoni kodin me kujdes, me siguri keni kuptuar se për t'u shfaqur në faqe ne përdorim shabllonin first_layouts dhe pamjen (shfaqjen) index.php - kodin e tij e dhashë pak më lart. Gjithçka që na mbetet është të krijojmë skedarin e shabllonit first_layouts. Vendoseni në dosjen /views/layouts/first_layouts.php
Modeli do të përmbajë kodin e mëposhtëm:

kokë

fundi i faqes

Kjo është e gjitha, kjo përfundon krijimin e "kornizës". Tani kemi strukturën më të thjeshtë të bazuar në modelin MVC. Në këtë artikull, nuk e preka punën me bazën e të dhënave, thjesht e përmenda kalimthi, pasi artikulli ishte tashmë i gjatë. Unë do të përshkruaj drejtpërdrejt punën me bazën e të dhënave në artikullin vijues.
Kjo përfundon artikullin, ju mund të shkarkoni burimet në arkiv.

Modeli Model-View-Controller (MVC), i zbuluar në fund të viteve 1970, është një model dizajni i arkitekturës softuerike që fokusohet në shkëputjen e funksioneve të të dhënave nga prezantimi i tyre. Në teori, një aplikacion MVC i dizajnuar mirë do t'u lejojë zhvilluesve të nivelit të përparmë dhe atij të fundit të mos ndërhyjnë në fushat e përgjegjësisë së njëri-tjetrit gjatë punës së tyre, domethënë, zhvilluesi i pjesës së përparme nuk ka nevojë të dijë asgjë për "kuzhinën". " të kolegut të tij të fundit dhe anasjelltas.

Edhe pse fillimisht i projektuar për zhvillimin e aplikacioneve desktop, MVC është përshtatur për nevojat e sotme dhe është jashtëzakonisht popullor me zhvilluesit e uebit, sepse ndarja e shqetësimeve ka bërë të mundur krijimin e kodit më të qartë dhe të ripërdorshëm. Modeli MVC rezulton në sisteme të qarta, modulare që lejojnë zhvilluesit të bëjnë ndryshime në kodin ekzistues shumë shpejt.

Në këtë artikull, ne do t'ju ecim me bazat e MVC, duke filluar duke përcaktuar një model dhe duke vazhduar me një shembull të vogël. Ky artikull do të jetë kryesisht i dobishëm për ata që nuk e kanë hasur kurrë këtë model në jetën e tyre, dhe gjithashtu, ndoshta, për ata që dëshirojnë të mësojnë njohuritë e tyre për MVC.

Kuptimi i MVC

Siç është përmendur tashmë, emri i modelit vjen nga shkurtimi i tre fjalëve: Model Pamje dhe Kontrolluesi... Shkurtimisht, parimi i modelit mund të ilustrohet me një diagram (mund të gjendet në Wikipedia):

Ky diagram tregon qartë rrjedhën e njëanshme të informacionit në model, dhe gjithashtu përshkruan rolet e secilit komponent.

Model

Modeli përdoret për të aksesuar dhe manipuluar të dhënat. Në shumicën e rasteve, një model është ai që përdoret për të hyrë në një dyqan të dhënash (siç është një bazë të dhënash). Modeli ofron një ndërfaqe për marrjen, krijimin, modifikimin dhe fshirjen e të dhënave nga ruajtja. Në kontekstin e modelit MVC, modeli ndërmjetëson midis pamjes dhe kontrolluesit.

Një tipar jashtëzakonisht i rëndësishëm i modelit është se ai teknikisht nuk ka njohuri se çfarë po ndodh me të dhënat në kontrollues dhe pamjen. Modeli kurrë nuk duhet të bëjë ose të presë ndonjë kërkesë për / nga komponentët e tjerë të modelit.

Sidoqoftë, mbani mend gjithmonë se një model nuk është vetëm një portë për një bazë të dhënash ose sistem tjetër që nuk bën asgjë tjetër veçse i kalon të dhënat përpara dhe mbrapa. Një model është si një portë për të dhëna. Modeli është në shumicën e rasteve pjesa më komplekse e sistemit, pjesërisht sepse vetë modeli është ngjitës për të gjitha pjesët e tjera.

Përfaqësimi

Pamja është ajo ku të dhënat e marra nga modeli shfaqen në formën e dëshiruar. Në aplikacionet tradicionale të ueb-it të zhvilluara me modelin MVC, një pamje është pjesa e sistemit ku gjenerohet HTML. Pamja është gjithashtu përgjegjëse për marrjen e veprimeve nga përdoruesi në mënyrë që t'i dërgojë ato te kontrolluesi. Për shembull, një pamje jep një buton në ndërfaqen e përdoruesit, dhe pasi e klikoni atë, thërret veprimin përkatës të kontrolluesit.

Ka disa keqkuptime rreth qëllimit të pamjes, veçanërisht midis zhvilluesve të uebit që sapo kanë filluar të ndërtojnë aplikacionet e tyre duke përdorur MVC. Një nga rregullat që shkelen më shpesh është se pamja nuk duhet të komunikojë me modelin në asnjë mënyrë, dhe të gjitha të dhënat e marra nga pamja duhet të vijnë vetëm nga kontrolluesi... Në praktikë, zhvilluesit shpesh e injorojnë këtë koncept, i cili është në thelb të modelit MVC. Artikulli i Fabio Cevasco ilustron këtë qasje konfuze ndaj MVC duke përdorur CakePHP, një nga shumë korniza jo standarde MVC:

Është jashtëzakonisht e rëndësishme të kuptohet se për të marrë arkitekturën e saktë MVC, nuk duhet të ketë ndërveprime të drejtpërdrejta midis pamjeve dhe modeleve. E gjithë logjika e shkëmbimit të të dhënave ndërmjet tyre duhet të zbatohet në kontrollues.

Përveç kësaj, ekziston një keqkuptim i zakonshëm që një pamje është thjesht një skedar shabllon. Siç vuri në dukje Tom Butler, ky keqkuptim ka një shkallë të madhe për faktin se shumë zhvillues e keqkuptojnë strukturën MVC që në fillim, pas së cilës ata fillojnë ta derdhin këtë "dije" më tej, masat e zhvilluesve fillestarë. Në realitet, një pamje është shumë më tepër sesa thjesht një shabllon, por shumë korniza të ndërtuara mbi bazën e modelit MVC e kanë shtrembëruar konceptin e një pamjeje aq shumë sa që askujt nuk i intereson se sa korrekte janë aplikimet e tyre për sa i përket modelit MVC.

Është gjithashtu e rëndësishme që pamja të mos funksionojë kurrë me të dhëna "të pastra" nga kontrolluesi, domethënë kontrolluesi nuk punon kurrë me pamjen duke anashkaluar modelin. Në procesin e ndërveprimit ndërmjet kontrolluesit dhe pamjes, modeli duhet të jetë gjithmonë ndërmjet tyre.

Kontrolluesi

Kontrolluesi është pjesa e fundit e grupit MVC. Detyra e kontrolluesit është të marrë të dhëna nga përdoruesi dhe të manipulojë modelin. Është kontrolluesi, dhe vetëm ai, që është pjesa e sistemit që ndërvepron me përdoruesin.

Me pak fjalë, një kontrollues mund të përshkruhet si një mbledhës informacioni që e transferon atë në një model për përpunim dhe ruajtje. Ai nuk duhet të bëjë asgjë me të dhënat, por vetëm të jetë në gjendje t'i marrë ato nga përdoruesi. Kontrolluesi shoqërohet me një pamje dhe një model, duke organizuar kështu një rrjedhë të dhënash të njëanshme, duke e kontrolluar atë në çdo fazë.

Është shumë e rëndësishme të mbani mend se kontrolluesi fillon punën e tij vetëm si rezultat i ndërveprimit të përdoruesit me pamjen, e cila thërret funksionin përkatës të kontrolluesit. Gabimi më i zakonshëm midis zhvilluesve është trajtimi i një kontrolluesi thjesht si një portë midis pamjes dhe modelit. Si rezultat, kontrolluesi është i pajisur me funksionet që duhet të kryejë pamja (nga rruga, këtu vjen ideja se pamja është vetëm një skedar shabllon). Për më tepër, shumë njerëz hedhin fare logjikën e përpunimit të të dhënave, duke harruar se për çfarë synohet modeli në modelin MVC.

MVC në PHP

Unë sugjeroj të përpiqeni të zbatoni sa më sipër në një aplikacion të vogël. Le të fillojmë duke krijuar klasat Model, View dhe Controller:

string = "MVC + PHP = I mrekullueshëm!"; ))kontrollues = kontrollues $; $ kjo->

". vargu $ this-> model->."

"; } } model = modeli $; ))

Klasat kryesore janë gati. Tani, le t'i lidhim ato së bashku dhe të ekzekutojmë aplikacionin tonë:

prodhimi ();

Siç mund ta shihni, kontrolluesi nuk ka funksionalitet sepse përdoruesi nuk ndërvepron me aplikacionin në asnjë mënyrë. I gjithë funksionaliteti vendoset në pamje, pasi aplikacioni ynë është vetëm për shfaqjen e të dhënave.

Le ta zgjerojmë pak aplikacionin duke shtuar një interaktivitet për të parë se si funksionon kontrolluesi:

string = “MVC + PHP = E mrekullueshme, kliko këtu!”; ))kontrollues = kontrollues $; $ ky-> modeli = modeli $; ) prodhimi i funksionit publik () (kthimi "

model-> varg. "

"; } } model = modeli $; ) funksioni publik i klikuar () ($ this-> model-> string = “Të dhënat e përditësuara, falë MVC dhe PHP!”))

Më në fund, le të përditësojmë pak kodin e ngjitësit:

($ _GET ["veprim"]) (); ) echo $ view-> output ();

Rezultatet

Në këtë artikull të shkurtër, ne mbuluam konceptet bazë të modelit të dizajnit MVC dhe zhvilluam një aplikacion të thjeshtë bazuar në të, megjithëse sigurisht që jemi ende shumë larg përdorimit të tij në jetën reale. Në artikullin vijues, do të shohim vështirësitë kryesore me të cilat do të përballeni nëse jeni më të fokusuar në ndërtimin e një arkitekture aplikacioni bazuar në modelin MVC. Qëndroni të sintonizuar!

Në këtë tutorial, do të mësoni se si të ndërtoni një sistem të thjeshtë arkitekture MVC (Model-View-Controller) në PHP 5.1 duke përdorur aftësitë e bibliotekës SPL (Standard PHP Library).

Prezantimi

Mirë se vini në tutorialin e parë të plotë për PHP 5. Do t'ju duhet PHP 5.1 me SPL të instaluar pasi ne do të përfitojmë nga disa nga veçoritë më të fundit të PHP 5.

Në këtë tutorial, unë do t'ju tregoj se si të ndërtoni një sistem të thjeshtë MVC (arkitektura MVC është modeli më i zakonshëm i dizajnit për aplikacione të mëdha ueb). Unë do t'ju udhëzoj nëpër të gjitha hapat nga fillimi në fund të krijimit të një sistemi të plotë MVC.

Një pikë hyrjeje

Një nga gjërat e rëndësishme në lidhje me MVC është një pikë hyrëse në aplikacion në vend të një grupi skedarësh PHP që bëjnë diçka të tillë:

Ne do të kemi një skedar që trajton të gjitha kërkesat. Kjo do të thotë që ne nuk duhet të shqetësohemi për lidhjen me global.php sa herë që na duhet të krijojmë një faqe të re. Kjo "pikë e vetme hyrëse" do të quhet index.php dhe tani për tani do të jetë:

Siç mund ta shihni, ky skenar nuk bën asgjë ende, por prisni një minutë.

Për të drejtuar të gjitha kërkesat në faqen kryesore, ne do të përdorim mod_rewrite dhe do të vendosim direktivën RewriteRule në .htaccess. Le të vendosim kodin e mëposhtëm në skedarin .htaccess dhe ta ruajmë në të njëjtën direktori si index.php:

RewriteEngine në RewriteCond% (REQUEST_FILENAME)! -F RewriteCond% (REQUEST_FILENAME)! -D RewriteRule ^ (. *) $ Index.php?Rruga = 1 $

Së pari, kontrollojmë nëse skedari i kërkuar ekziston duke përdorur direktivën RewriteCond, dhe nëse jo, atëherë e ridrejtojmë kërkesën te index.php. Ky kontroll për ekzistencën e skedarit është i nevojshëm, pasi në të kundërt index.php do të përpiqet të përpunojë të gjitha kërkesat në sajt, duke përfshirë kërkesat për imazhe. Dhe ne thjesht nuk kemi nevojë për këtë.

Nëse nuk jeni në gjendje të përdorni .htaccess ose mod_rewrite, atëherë do t'ju duhet t'i adresoni manualisht të gjitha kërkesat në index.php. Me fjalë të tjera, të gjitha lidhjet duhet të jenë të formës "index.php? Route = [kërkesa shkon këtu]". Për shembull, "index.php? Route = chat / index".

Tani që të gjitha kërkesat kalojnë në të njëjtën pikë hyrëse, mund të fillojmë të shkruajmë skriptin index.php. Gjëja e parë që duhet të bëjmë është të inicializojmë sistemin. Le të krijojmë direktoriumin e përfshirjes dhe në të skedarin startup.php (do ta kemi si skedar inicializimi). Le të ngjisim kodin e mëposhtëm në index.php:

Në këtë shembull, ne deklarojmë disa konstante, zbulojmë se ku janë skedarët e sistemit dhe gjithashtu kontrollojmë që versioni PHP është, mirë, të paktën 5.1.

Gjëja tjetër që duhet të bëni është një objekt Regjistri për të ruajtur vlerat globale. Ai do t'i kalohet objekteve të veçanta në sistem dhe do të përdoret për të hyrë në vlerat globale, dhe pa nevojën për të përcaktuar variablat si "global" ose për të hyrë në grupin $ GLOBALS. Shihni artikullin "Përdorimi i vlerave globale në PHP" për më shumë informacion mbi objektin e regjistrit.

Shtoni kodin e mëposhtëm në skedarin tuaj startup.php pas shembullit të mëparshëm:

$ regjistri = regjistër i ri;

Nëse përpiqeni të nisni sistemin tani, mund të shihni gabimin e mëposhtëm:

Gabim fatal: Klasa "Registry" nuk u gjet në g: \ Projektet \ PHP \ përmbajtje \ mvc thjeshtë php5 \ demo \ përfshin \ startup.php në linjën 12

Kjo, natyrisht, nuk është një surprizë e madhe për ne, pasi ne nuk e kemi shkruar ende vetë klasën e Regjistrit. Skedari me klasën thjesht mund të përfshihet duke përdorur funksionin include () (Shënim korsi: meqë ra fjala, përfshirja () nuk është një funksion i tillë, por gjithsesi një shprehje gjuhësore, një strukturë kontrolli, nëse shikoni manualin) por le të përdorim një nga veçoritë e reja në PHP 5: __autoload ().

Funksioni magjik __autoload () përdoret për të ngarkuar në mënyrë dinamike klasa. Kur PHP zbulon një klasë joekzistente, fillimisht thërret funksionin __autoload () dhe vetëm më pas hedh një gabim. Ne mund të përfitojmë nga kjo mundësi për të ngarkuar klasat në fluturim.

Ngjitni këtë kod përpara kodit nga shembulli i mëparshëm:

// Ngarkoni klasat në funksionin e fluturimit __autoload ($ class_name) ($ filename = strtolower ($ class_name). ".Php"; $ file = site_path. "Classes". DIRSEP. $ Filename; if (file_exists ($ file) = = false) (ktheje false;) përfshin (skedarin $);)

Funksioni ynë __autoload () merr emrin e klasës që i është transmetuar si argument dhe kontrollon nëse një skedar me një emër të ngjashëm ekziston në drejtorinë e klasës. Nëse nuk ka skedar, atëherë funksioni thjesht do të kthehet false dhe do të shfaqet një gabim fatal. Por nëse skedari ekziston, ai do të ngarkohet. ato. do të deklarohet klasa e kërkuar dhe nuk do të ketë asnjë gabim.

Ne nuk e kemi krijuar ende vetë klasën e Regjistrit, kështu që gabimi do të shfaqet ende. Le të zbresim në të.

Krijimi i klasës së Regjistrit

Klasa Registry përdoret për të kaluar vlerat globale midis objekteve individuale. Është në fakt një klasë mjaft e thjeshtë që duhet të zbatojë disa metoda të vogla.

Së pari, le të krijojmë një drejtori klasash dhe një skedar registry.php në të. Le të ngjisni kodin e mëposhtëm në registry.php:

Tani kemi një "skelet" të klasës Registry dhe duhet ta ngarkojmë me metoda. Le të shkruajmë 2 metoda: vendosni () për të vendosur vlerat dhe merrni () për të marrë vlera. Ju gjithashtu mund të shkruani një metodë heqje () për të hequr vlerat. Le të shtojmë këto metoda në klasën e Regjistrit:

Kompleti i funksionit (kyç $, $ var) (if (isset ($ this-> vars [$ key]) == true) (hedh Përjashtim të ri ("Nuk mund të vendoset var" ". $ Key." ". Tashmë është vendosur. ");) $ this-> vars [$ key] = $ var; kthe e vërtetë;) Funksioni merr (kyç $) (if (isset ($ this-> vars [$ key]) == false) (kthimi null; ) kthe $ this-> vars [kyç $];) funksion heq ($ var) (unset ($ this-> vars [$ key]);)?>

Këto metoda janë të thjeshta, ato vendosin, marrin dhe heqin elemente nga grupi $ vars, i cili është një atribut i klasës. Në metodën set (), ne gjithashtu kontrollojmë nëse vlera me çelësin e specifikuar tashmë ekziston, dhe nëse ekziston, atëherë hedhim një përjashtim. Kjo është për të shmangur mbishkrimin aksidental të vlerave.

Tani kemi një klasë të plotë të Regjistrit, por nuk do të ndalemi në këtë. Le të përdorim një nga veçoritë e bibliotekës SPL: ArrayAccess. SPL (shkurt për Standard PHP Library) është një koleksion ndërfaqesh dhe klasash të krijuara për të zgjidhur problemet e zakonshme. Një nga ndërfaqet SPL, ArrayAccess, mund të përdoret për të siguruar akses në një objekt si një grup i rregullt. Le të shohim një shembull si ky:

grup ("emri", "Dennis Pallett"); // Merrni vlerën duke përdorur get () echo $ registry-> get ("emri"); // Merre vlerën duke përdorur regjistrin e regjistrit echo të aksesit në grup ["emri"]?>

Truku është se regjistri $ bëhet si një grup, kur në fakt është një objekt. Sigurisht, ArrayAccess nuk ofron ndonjë avantazh të veçantë, por ju lejon të zvogëloni sasinë e kodit, pasi nuk keni nevojë të shkruani "-> merrni ()" çdo herë. Për të përdorur këtë ndërfaqe, duhet të rregulloni rreshtin e parë të klasës ("Regjistri i klasës") si më poshtë:

Regjistri i klasës zbaton ArrayAccess (

Fjala kyçe Implements i tregon interpretuesit se kjo është klasa që ne po implementojmë ndërfaqen, e cila është ajo që është ArrayAccess.

Një klasë që implementon ndërfaqen ArrayAccess duhet të ketë metodat e mëposhtme:

Funksioni offsetEkziston ($ offset) (kthimi i caktuar ($ this-> vars [$ offset]);) funksioni offsetGet ($ offset) (kthimi $ this-> merrni ($ offset);) funksioni offsetSet ($ offset, $ vlera) ($ this-> set ($ offset, $ vlera);) funksioni offsetUnset ($ offset) (unset ($ this-> vars [$ offset]);)

Këto metoda duhet të jenë vetë-shpjeguese. Më shumë informacion mund të gjeni në dokumentacionin SPL.

Tani që kemi implementuar ndërfaqen ArrayAccess, ne mund të aksesojmë objektin sikur të ishte një grup i zakonshëm. Kjo tregohet qartë, si në shembullin e mëparshëm ashtu edhe në këtë:

marr ("emri"); // Merre vlerën duke përdorur regjistrin e regjistrit echo të aksesit në grup ["emri"]?>

Klasa e Regjistrit tani ka përfunduar dhe nëse përpiqeni të nisni sistemin, gjithçka duhet të funksionojë (edhe pse asgjë nuk do të dalë ende). Ne kemi përfunduar me skedarin e inicializimit dhe mund të kalojmë në hapin tjetër në shkrimin e sistemit tonë MVC: implementimi i aksesit në bazën e të dhënave, i cili quhet "Model" në arkitekturën MVC.

Model

"M" ose modeli është pjesa e sistemit MVC që është përgjegjëse për kërkimin e bazës së të dhënave (ose burimeve të tjera të jashtme) dhe sigurimin e informacionit për kontrolluesin. Do të ishte e mundur të ngarkohej modeli i kërkuar në varësi të kërkesës, por unë preferoj të fshij pak kufijtë midis modelit dhe kontrolluesit pikërisht në këtë pikë, d.m.th. kontrolluesi punon me bazën e të dhënave drejtpërdrejt përmes bibliotekës së ndërveprimit të bazës së të dhënave, dhe jo përmes një modeli të veçantë. Ndoshta ju dëshironi ta bëni ndryshe, është çështje shije.

Duhet të shkruajmë kodin e nevojshëm për të krijuar një lidhje me bazën e të dhënave dhe ta vendosim në index.php. Ka shumë biblioteka të shkëlqyera për të punuar me bazat e të dhënave (përfshirë timen, AutoCRUD), por PHP 5 tashmë ka një bibliotekë të tillë - PDO. Prandaj, nuk ka nevojë të përdorni ndonjë tjetër.

Le të fusim kodin e mëposhtëm në skedarin index.php (pasi të lidhim skedarin e inicializimit):

# Lidhu me bazën e të dhënave $ db = PDO e re ("mysql: host = localhost; dbname = demo", "", ""); $ registry-> set ("db", $ db);

Në këtë shembull, ne fillimisht krijojmë një shembull të ri të bibliotekës PDO dhe lidhemi me bazën tonë të të dhënave MySQL. Pastaj ne e bëjmë variablin $ db të disponueshëm globalisht duke përdorur klasën tonë të Regjistrit.

Komponenti model i sistemit tonë është gati, kështu që le të kalojmë në shkrimin e kontrolluesit.

Shkrimi i një kontrolluesi nënkupton gjithashtu shkrimin e një klase Router që është përgjegjëse për ngarkimin e kontrolluesit të dëshiruar në varësi të kërkesës (mbani mend, në index.php, ndryshorja $ route kalon përmes URL-së).

Klasa e ruterit

Klasa Router do të analizojë kërkesën dhe më pas do të ngarkojë kontrolluesin e kërkuar. Le të krijojmë një "skelet" të klasës:

regjistri = regjistri $; ))?>

Pastaj shtoni rreshtat e mëposhtëm në index.php:

# Ngarko ruterin $ router = ruter i ri (regjistri $); $ registry-> set ("ruteri", $ router);

Gjëja e parë që do të shkruajmë është metoda setPath () për të vendosur drejtorinë ku do të vendosen të gjithë kontrollorët tanë. Metoda duket si kjo dhe duhet të shtohet në klasën Router:

Funksioni setPath (shtegu $) (shtegu $ = shkurtimi (shtegu $, "/ \\"); shtegu i $. = DIRSEP; nëse (is_dir (shtegu i $) == i gabuar) (hedh një përjashtim të ri ("Rruga e pavlefshme e kontrolluesit:` ". $ shteg." `");) $ this-> shteg = $ shteg;)

Pastaj shtoni rreshtat e mëposhtëm në index.php:

$ router-> setPath (shtegu_site. "kontrolluesit");

Tani që kemi vendosur rrugën drejt kontrolluesve tanë, do të shkruajmë vetë metodën përgjegjëse për ngarkimin e kontrolluesit. Kjo metodë do të quhet delegate () dhe do të analizojë kërkesën. Pjesa e parë e kësaj metode është kjo:

Funksioni delegat () (// Analizoni shtegun $ this-> getController ($ file, $ controller, $ action, $ args);

Siç mund ta shihni, ai përdor një metodë tjetër, getController (), për të marrë emrin e kontrolluesit dhe disa variabla të tjerë. Kjo metodë duket si kjo:

Funksioni privat getController (& $ skedar, & $ kontrollues, & $ veprim, & $ args) ($ route = (bosh ($ _ GET ["rrugë"]))? "": $ _GET ["rrugë"]; nëse ( bosh ($ itinerari)) ($ route = "indeks";) // Merr pjesët e ndara $ route = trim ($ route, "/ \\"); $ pjesë = shpërthejnë ("/", $ route); ( ) ($ cmd_path . = $ pjesë. DIRSEP; array_shift ($ pjesë); vazhdim;) // Gjeni skedarin if (is_file ($ fullpath. ".php")) ($ controller = $ pjesë; array_shift ($ pjesë) ; thyej;)) nëse (bosh ($ kontrollues)) ($ kontrollues = "indeks";); // Merr veprimin $ action = shift_array ($ pjesë); nëse (bosh ($ veprim)) ($ veprim = " index";) skedar $ = $ cmd_path. $ kontrollues. ".php"; $ args = $ pjesë;)

Le të kalojmë mbi këtë metodë. Së pari, merr vlerën e ndryshores së rrugës $ nga kërkesa, më pas e ndan atë në pjesë duke përdorur funksionin explode (). Për shembull, kërkesa "anëtarë / pamje" do të konvertohej në një grup si ky: grup ('anëtarë', 'pamje').

Pastaj kalon nëpër secilën pjesë duke përdorur një lak foreach dhe kontrollon nëse ajo pjesë është një direktori. Nëse është, atëherë e bashkëngjit atë në shtegun e skedarit dhe kontrollon pjesën tjetër. Kjo ju lejon të vendosni kontrollues në nëndrejtori dhe kështu të merrni një hierarki të kontrolluesve. Nëse pjesa aktuale e kërkesës nuk është një direktori, por një skedar, ajo ruhet në ndryshoren e kontrolluesit $ dhe ne dalim nga cikli, pasi u gjet kontrolluesi që na nevojitet.

Pas lakut, kontrollojmë variablin me emrin e kontrolluesit. Nëse është bosh, atëherë përdorim kontrolluesin "indeks", i cili do të jetë kontrolluesi ynë i paracaktuar. Metoda më pas përcakton veprimin që duhet ndërmarrë. Një kontrollues është një klasë që përbëhet nga disa metoda. Veprimi tregon për një metodë specifike. Nëse nuk specifikohet asnjë veprim, ne do të përdorim "indeksin" - veprimin e paracaktuar.

Më në fund, ne marrim shtegun e plotë drejt skedarit të kontrolluesit duke bashkuar tre variabla: shtegun, emrin e kontrolluesit dhe shtrirjen "php".

Tani që kemi analizuar kërkesën, është koha për të thirrur metodën delegate () për të ngarkuar kontrolluesin dhe për të ekzekutuar veprimin. Metoda e plotë e delegatit () duket si kjo:

Funksioni delegat () (// Analizoni shtegun $ this-> getController ($ file, $ controller, $ action, $ args); // A është skedari i disponueshëm? Nëse (is_readable ($ file) == false) (die ( "404 Nuk u gjet ");) // Përfshi skedarin të përfshijë (skedarin $); // Krijo një shembull të kontrolluesit $ class =" Controller_ ". $ Controller; $ controller = i ri $ class ($ this-> regjistri) ; // A është i disponueshëm veprimi? Nëse (is_callable (array ($ controller, $ action)) == false) (die ("404 Not Found");) // Ekzekutoni veprimin $ controller -> $ action (); )

Pas analizimit të kërkesës duke përdorur metodën getController (), kontrollojmë nëse skedari ekziston në të vërtetë dhe nëse jo, kthejmë një mesazh të thjeshtë gabimi.

Pas kësaj, ne e lidhim skedarin me kontrolluesin dhe krijojmë një shembull të klasës së tij, i cili duhet të quhet "Controller_ [emri]". Për kontrollorët do të flasim më në detaje më vonë.

Pastaj kontrollojmë nëse veprimi i specifikuar (d.m.th. metoda) ekziston dhe nëse është e mundur ta thërrasim atë (për këtë përdorim funksionin is_callable ()). Së fundi, ne kryejmë vetë veprimin, i cili është roli i klasës Router dhe përfundon.

Tani që kemi shkruar të gjithë metodën delegate (), shtoni rreshtin e mëposhtëm në skedarin tonë index.php:

$ router-> delegate ();

Nëse përpiqemi të nisim sistemin tani, do të shohim gabimin e mëposhtëm (natyrisht, nëse drejtoria e kontrollorëve nuk ekziston ende):

Gabim fatal: Përjashtim i pakapur "Përjashtim" me mesazhin "Rruga e pavlefshme e kontrolluesit:` g: \ Projektet \ PHP \ përmbajtje \ mvc thjeshtë php5 \ demo \ kontrolluesit \ `" në g: \ Projektet \ PHPit \ përmbajtje \ i thjeshtë mvc php5 \ demo \ classes \ router.php: 18 Gjurma e stivës: # 0 g: \ Projektet \ PHP \ përmbajtje \ mvc thjeshtë php5 \ demo \ index.php (13): Router-> setPath ("g: \ Projektet \ PHP ... ") # 1 (kryesore) e hedhur në g: \ Projektet \ PHP \ përmbajtje \ mvc e thjeshtë php5 \ demo \ klasa \ router.php në linjën 18

Ose do të shohim një gabim "404 Nuk u gjet", pasi nuk ka ende kontrollues. Por kjo është ajo që ne do të bëjmë tani.

Kontrolluesi

Kontrollorët në sistemin tonë MVC do të jenë mjaft të thjeshtë dhe do të marrin shumë pak kohë. Së pari, sigurohuni që drejtoria e kontrollorëve ekziston. Le të krijojmë një skedar controller_base.php në drejtorinë e klasave dhe ngjisni kodin e mëposhtëm në të:

regjistri = regjistri $; ) indeksi i funksionit abstrakt (); )?>

Kjo klasë abstrakte do të jetë klasa mëmë për të gjithë kontrollorët tanë. Ai do të bëjë vetëm dy gjëra: të mbajë një kopje lokale të klasës Registry dhe të përdorë metodën e indeksit abstrakt () për të detyruar të gjithë kontrollorët fëmijë të zbatojnë këtë metodë.

Le të shkruajmë kontrolluesin tonë të parë. Le të krijojmë një skedar index.php në direktorinë e kontrollorëve dhe ngjisni kodin e mëposhtëm në të:

Ne sapo kemi krijuar kontrolluesin tonë të parë dhe nëse përpiqeni të nisni sistemin, mund të shihni sa vijon:

Kjo do të thotë që klasa Router ka bërë punën e saj dhe ka aktivizuar veprimin e kërkuar nga kontrolluesi i kërkuar. Le të shkruajmë një kontrollues tjetër që përputhet me kërkesën "anëtarë / pamje". Le të krijojmë një skedar anëtarë.php në drejtorinë e kontrollorëve dhe të fusim kodin e mëposhtëm në të:

Tani le të shkojmë në sistemin tonë MVC me kërkesën "anëtarë / pamje" ose "index.php? Route = anëtarë / pamje". Ne duhet të shohim një rezultat si ky:

Vetëm duke shkruar një kontrollues të ri dhe duke shtuar një metodë në të, ne mundëm të krijonim një faqe të re dhe asgjë nuk duhej ndryshuar në vetë sistemin. Gjithashtu, kontrollorët tanë nuk kanë nevojë të përfshijnë një skedar global.php ose diçka të tillë.

Tani që kemi kontrollorët tanë, ka mbetur vetëm një gjë: "V" ose "View".

Ekrani

Ashtu si me modelet, ka disa opsione të ndryshme për krijimin e një komponenti View në një sistem MVC. Ne mund t'i mësojmë klasës Router të ngarkojë automatikisht një skedar tjetër të quajtur diçka si "view_ (emri) .php". Por për ta bërë tutorialin më të qartë, le të shkruajmë një klasë Template që do të trajtojë paraqitjen e shablloneve.

Së pari, krijoni një skedar template.php në drejtorinë e klasave dhe ngjisni kodin e mëposhtëm në të:

regjistri = regjistri $; ))?>

Tani kemi strukturën kryesore për klasën tonë Template. Hapi tjetër është shtimi i këtij kodi në skedarin tonë index.php, pikërisht përpara linjave të lidhura me klasën Router:

# Krijo një objekt shabllon $ template = model i ri ($ regjistri); $ registry-> set ("shabllon", $ template);

Meqenëse duhet të përdorim vlera nga modelet dhe kontrollorët, do të shkruajmë një metodë set () për të vendosur variablat e disponueshëm në shabllone. Le të shohim një shembull:

Kompleti i funksionit ($ varname, $ vlera, $ overwrite = false) (if (isset ($ this-> vars [$ varname]) == e vërtetë DHE $ overwrite == false) (gabim_shkaku ("Nuk mund të vendoset var` ". $ varname. "'. Është vendosur tashmë dhe nuk lejohet mbishkrimi.", E_USER_NOTICE); kthe false;) $ this-> vars [$ varname] = $ vlerë; kthe e vërtetë;) funksioni hiqni ($ varname) (i pacaktuar ($ this-> vars [$ varname]); kthe e vërtetë;)

Metodat set () dhe remove () janë mjaft të thjeshta dhe përdoren për të vendosur dhe hequr variabla, përkatësisht.

Le të fillojmë të shkruajmë një metodë të shfaqjes () që do të shfaqë shabllone. Mënyra më e thjeshtë është të krijoni një direktori të veçantë shabllonesh për të ruajtur të gjithë skedarët e shablloneve dhe të përdorni përfshirjen () për të dhënë shabllonin. Sigurisht, metoda juaj e shfaqjes () mund të jetë krejtësisht e ndryshme dhe të ngarkojë shabllonet nga baza e të dhënave ose të bëjë diçka tjetër. Le të shohim kuso

Vota: 745 | Shikime: 8080

Përkundër faktit se kuptimi i shprehjes "arkitektura e faqes" mund të jetë intuitiv për ju, le të përpiqemi të studiojmë një sërë përkufizimesh në pronësi të burimeve me reputacion.

Arkitekturë- ky është organizimi bazë i sistemit, i mishëruar në përbërësit e tij, marrëdhëniet e tyre me njëri-tjetrin dhe me mjedisin, si dhe parimet që përcaktojnë hartimin dhe zhvillimin e sistemit.

Arkitekturë një program ose një sistem kompjuterik është struktura ose strukturat e një sistemi që përfshin elementet e një programi, vetitë e këtyre elementeve të dukshme nga jashtë dhe marrëdhëniet ndërmjet tyre [Bas].

Arkitekturëështë struktura e organizatës dhe sjellja shoqëruese e sistemit. Një arkitekturë mund të çmontohet në mënyrë rekursive në pjesë që ndërveprojnë përmes ndërfaqeve, marrëdhënieve që lidhin pjesët dhe kushteve të montimit për pjesët. Pjesët që ndërveprojnë përmes ndërfaqeve përfshijnë klasat, komponentët dhe nënsistemet.

Arkitekturë Një sistem softuerik ose grup sistemesh përbëhet nga të gjitha vendimet e rëndësishme të projektimit në lidhje me strukturat e një programi dhe ndërveprimet midis atyre strukturave që përbëjnë sistemin. Vendimet e projektimit ofrojnë grupin e dëshiruar të vetive që një sistem duhet të mbështesë në mënyrë që të jetë i suksesshëm. Zgjidhjet e projektimit ofrojnë një kornizë konceptuale për projektimin, mbështetjen dhe mirëmbajtjen e sistemit.

Pra, çfarë është arkitektura e programit?

Përkufizimet e dhëna në pjesën e mëparshme janë shumë të thata për perceptimin e tyre nga një lexues i papërgatitur. Ne do të përpiqemi të shpjegojmë thelbin sa më thjesht të jetë e mundur.

Kur programi bëhet mjaft i madh, programuesi e ndan atë në skedarë të shumtë. Nëse nuk mendoni për izolimin e grupeve të funksioneve të ngjashme dhe vendosjen e tyre në module të veçanta, një ndarje e tillë do të jetë pak e dobishme. Kodi nuk do të jetë i ripërdorshëm dhe do të jetë i vështirë për t'u naviguar. Programi do të jetë i vështirë për tu zgjeruar dhe modifikuar.

Kështu, pyetja e parë po përgatitet: si ta ndani programin në skedarë. Arkitektura e skedarit të një programi është një aspekt i strukturës së tij.

Gjatë nënvizimit të moduleve të sistemit, është e nevojshme të kuptohet se në çfarë raporti do të jenë ato me njëri-tjetrin. Për shembull, modulet për hyrjen në bazën e të dhënave dhe përpunimin e imazheve grafike vështirë se kanë nevojë të dinë asgjë për ekzistencën e njëri-tjetrit. Por moduli UI do të dijë për të dy (dhe ata nuk do të dinë).

Marrëdhënia midis përbërësve të një sistemi përcaktohet gjithashtu nga arkitektura e tij.

Në përgjithësi, të gjitha vendimet e rëndësishme që synojnë organizimin e një programi, dhe jo problemet e zgjidhura me ndihmën e tij, mund t'i atribuohen arkitekturës.

Nivelet e abstraksionit

Kur hartoni module (zgjedhja e grupeve të funksioneve dhe shpërndarja e tyre midis skedarëve në rastin e një qasjeje procedurale), është e rëndësishme të zgjidhni abstraksione dhe të përpiqeni t'i zbërtheni ato në disa nivele.

Modulet e nivelit të ulët janë sa më autonome, ato nuk varen nga pjesët e tjera të programit. Modulet e dizajnuara mirë izolojnë "botën e jashtme" nga ndërlikimet e detyrës në fjalë. Telefonuesi njeh vetëm ndërfaqen e modulit (funksionet e jashtme), pjesa e brendshme është e mbyllur për të.

Le të marrim një galeri fotografish si shembull. Informacioni rreth imazheve dhe përdoruesve ruhet në bazën e të dhënave, ndërfaqja e përdoruesit është e ndarë në pjesën e klientit dhe panelin e administratorit.

Struktura e programit mund të jetë siç tregohet në figurën më poshtë:

Ky shembull gjurmon tre nivele të abstraksionit.

Çdo program i destinuar për përdorim njerëzor mund të ndahet në të paktën dy nivele: ndërfaqja e përdoruesit dhe modeli. Moduli i ndërfaqes së përdoruesit është krijuar për të paraqitur dhe vizualizuar të dhënat dhe për të përpunuar reagimet e përdoruesit. Modeli përmban logjikën e problemit që zgjidhet dhe nuk duhet në asnjë mënyrë të varet nga mënyra se si shfaqen të dhënat. Modeli duhet të jetë lehtësisht i lëvizshëm midis llojeve të ndryshme të ndërfaqes së përdoruesit.

Arkitektura MVC

Popullore tani Modeli i projektimit MVC... Shërben për të ndarë logjikën e aplikacionit nga ndërfaqja e përdoruesit. Por së pari, le të sqarojmë se çfarë është një model dizajni.

Ky është një grup zgjidhjesh tipike të projektimit, një kornizë e një arkitekture ose fragmenti të saj. Nëse një bibliotekë është një paketë kodesh të ripërdorshme, atëherë një model dizajni është një paketë zgjidhjesh të ripërdorshme.

Pra, çfarë na ofron MVC për të shkëputur logjikën e aplikacionit nga ndërfaqja e përdoruesit?

Mostra MVC ju lejon të ndaheni të dhënat, prezantimi dhe përpunimi i veprimeve të përdoruesit në tre komponentë të veçantë:

1. Model... Modeli ofron të dhëna (zakonisht për Pamjen) dhe gjithashtu u përgjigjet kërkesave (zakonisht nga Kontrolluesi) duke ndryshuar gjendjen e tij;
2. Pamje... Përgjegjës për shfaqjen e informacionit (ndërfaqja e përdoruesit);
3. Kontrolluesi... Interpreton të dhënat e përdoruesit dhe informon modelin dhe pikëpamjen për nevojën për një përgjigje të përshtatshme.

Figura më poshtë tregon marrëdhëniet midis përbërësve të një kornize. Le ta ilustrojmë figurën me një shembull të vogël.

Imagjinoni një formë ku mund të futni tekst, klikoni butonin Edit dhe merrni transliterimin e tij:

Le të përsërisim hapat e treguar në diagram:

1. Përdoruesi klikon butonin Edit dhe Përfaqësimi(Shiko) dërgon një mesazh Kontrolluesi(Kontrolluesi): "Komanda: modifiko"
2. Kontrolluesi pranon mesazh dhe akseson Modelin duke thirrur metodën Edit ().
3. Si rezultat ndryshimet e modelit gjendjen e tij (teksti i transliteruar i ruajtur në të) dhe njofton pamjen për të: "Ngjarja: ndryshuar".
4. Dorëzimi merr sinjal dhe i referohet modelit për një vlerë të re rezultati duke thirrur metodën e tij Get ().

Zbatimi i MVC

Zbatimi MVC supozon një Përqasje të Orientuar në Objekt (OOP). Sidoqoftë, një model dizajni është vetëm një koleksion zgjidhjesh. Le t'i përshtatim ato për PHP pa përdorur OOP. Thjeshtimi është bërë për t'u përqendruar në thelbin e ndarjes së logjikës, dhe gjithashtu në mënyrë që materiali të mund të aplikohet nga një lexues që nuk është i njohur me OOP.

Konsideroni përsëri shembull me një galeri fotografish.
Ka dy mënyra shikimi:

1. Modaliteti i pamjes së miniaturës (të gjitha përnjëherë);
2. Modaliteti i pamjes së fotografisë me madhësi të plotë (të vetme).

Ekziston edhe një mundësi ngarkoni foto te serveri. Për më tepër, ne do të zbatojmë mbështetje për llojet e vizualizimit për të vlerësuar fleksibilitetin e kornizës.

Faqja do të dy pika hyrjeje:

1. index.php (shikoni galerinë);
2. photo.php (shikoni foton në madhësi të plotë).

Këto dy dosje do të merren parasysh Kontrollorët.

Si Modelet do të ketë një modul që ofron punë me ruajtjen e imazhit. Le ta quajmë atë galeria.php dhe vendoseni në dosje model.

Në rol Përfaqësimi Modelet HTML do të paraqiten, ato do të vendosen në dosje shabllone... Cilat janë shabllonet dhe për çfarë janë ato - do të shihet më tej.

Pamja e galerisë dhe faqet e pamjes së fotografive do të kenë një kokë dhe fund të përbashkët, vetëm pjesa qendrore do të ndryshojë.

Pamja e galerisë do të ketë dy lloje vizualizimesh:

1. Si tabelë (e parazgjedhur);
2. Pamja e listës.

Na duhen katër shabllone:

1. main.php (skeleti i faqes);
2. content_index_table.php (pamje tabelare e përmbajtjes së galerisë);
3. content_index_list.php (pamja e listës së përmbajtjes së galerisë);
4. content_photo.php (përmbajtja e faqes së shikimit të fotove).

Rezulton struktura e mëposhtme e faqes:

Struktura e skedarit ndahet nga dy vija horizontale që formojnë tre seksione. Skedarët në seksionin e sipërm i referohen Modelit, skedarët në seksionin e mesëm tek Pamja, skedarët në seksionin e poshtëm i referohen Kontrolluesit.

Model

Le të fillojmë me zbatimin e Modelit. Kodi më poshtë nuk është dhënë plotësisht për minimizimin dhe qartësinë më të mirë të shembullit.

Ne kemi përcaktuar vetëm ndërfaqen Model, duke e lënë zbatimin të anashkaluar. Megjithatë, për shembullin e zbatimit të kornizës MVC, nuk nevojitet fare.

Përfaqësimi

Tani le të shohim shabllonet. Le të fillojmë me një skelet të përgjithshëm faqesh:

Nuk duhet të ngatërrohesh nga fakti që shablloni përdor një burim të panjohur të variablave $ title dhe $ content. Ata do të zëvendësohen nga Kontrollori. Por më shumë për këtë më vonë.

është një shënim i shkurtuar .

Është i përshtatshëm për ta përdorur atë në shabllone. Është gjithashtu më i përshtatshëm të përdoren variante alternative të shkrimit të konstruksioneve if-else, foreach, for, while në shabllone. Ata duken kështu:

nese (<условие>): <тело>endif; per secilin (<инициализация цикла>): <тело>endforeach;

Pjesa tjetër e shablloneve do të futet në main.php në këtë mënyrë:

Në shembujt më poshtë, kodi i tyre tregohet:

Modelet / kodi content_index_table.php

tabela| Listë

"> " />

Templates / content_index_list.php

Tabela | Listë

"> " />

shabllonet / content_photo.php: Kthehu

" />

Kontrolluesi

Së fundi, le t'i bashkojmë të gjitha duke përshkruar dy kontrollorët tanë. Detyra e tyre është të përpunojnë kërkesën, të zgjedhin një shabllon dhe të zëvendësojnë të dhënat e kërkuara nga shablloni. Të dhënat merren, si rregull, nga modeli.

Kontrolluesi i galerisë ngarkon një foto nëse përdoruesi ka ngarkuar një skedar. Përndryshe, nxjerr një listë fotosh nga modeli, zgjedh shabllonin e dëshiruar (në varësi të dëshirës së përdoruesit) dhe shfaq këtë shabllon, duke i kaluar një listë fotosh:

Kodi Index.php

Kontrolluesi i pamjes së fotografisë është edhe më i thjeshtë:

Kodi Photo.php

Së fundi

Mundohuni t'i kushtoni vëmendje të mjaftueshme arkitekturës së aplikacionit tuaj. Nëse fillimisht krijoni një kornizë të fortë dhe të zgjerueshme, mundi do të shpërblehet njëqindfish.

Për të zbatuar modelin MVC, është më mirë të zgjidhni qasje e orientuar drejt objektit .

Ka shumë zgjidhje të kornizës jashtë kutisë, për shembull në Kornizën Zend. Megjithatë, informacioni në mësimin aktual është i mjaftueshëm për të kuptuar zgjidhjet arkitekturore MVC dhe për të filluar përdorimin e tyre tani.

Çfarë është MVC?

Pra, MVC ka të bëjë me ndërfaqen e përdoruesit (UI). Jo domosdoshmërisht grafik, kontrolli i zërit është gjithashtu i mirë. Të mos harrojmë se një program mund të mos ketë një ndërfaqe përdoruesi, mund të ketë një ndërfaqe programimi (API), ose mund të mos ketë fare, dhe gjithsesi të jetë i dobishëm.

Por nëse kemi një përdorues, atëherë duhet të ketë një ndërfaqe përdoruesi. Çfarë është një ndërfaqe? Ky është kufiri ngjitur midis dy sistemeve. Në rastin tonë: nga njëra anë - programi, nga ana tjetër - përdoruesi. Këtu ata janë.

Programi është plotësisht abstrakt, çdo kod lënde. Ajo di të bëjë diçka të dobishme, dhe përdoruesi ka nevoja që mund të kënaqen me këtë program. Pastaj shfaqen pjesë logjike që "dinë" se si, duke përdorur këtë program, të bëjnë drejtpërdrejt atë që dëshiron përdoruesi. Pjesët nuk janë subjekt, logjika e lëndës në program. Ato lidhen më shumë me përdoruesin me nevojat e tij specifike dhe janë kombinime të thirrjeve dhe thirrjeve në program.

Raste te perdorimit

Për shembull, imagjinoni një terminal për tregtimin në një bursë. Përdoruesi i terminalit vendos një aplikacion në të cilin ai tregon se dëshiron të blejë 20 aksione të kompanisë Svetlyi Put me një çmim prej 1500 RUB për aksion. Gjithashtu tregon se aplikacioni është i vlefshëm për katër orë, dhe nga cila llogari e tij duhet të debitohen paratë, në rast të një transaksioni të suksesshëm.

Një numër i prekshëm atributesh. Kalon ca kohë dhe ai e kupton se nuk do të jetë e mundur të blihet me një çmim të tillë dhe është gati të rrisë çmimin në 1550 rubla, duke lënë të gjitha vlerat e tjera. Pastaj ai zgjedh këtë aplikacion, klikon butonin "ndrysho", tregon një çmim të ri, po. Është komode.

Por rendi nuk mund të ndryshohet në shkëmbim, nuk ka një koncept të tillë në fushën e temës. Aplikimi mund të vendoset dhe anulohet vetëm. Për t'i dhënë përdoruesit mundësinë për të ndryshuar aplikacionin me një klikim, është e nevojshme të mbani mend vlerat e vjetra, të anuloni aplikacionin, t'i jepni për të redaktuar atë që ka memorizuar dhe të dorëzoni një aplikacion të ri. Një kombinim i tillë. Por për përdoruesin duket si një veprim i thjeshtë: ndryshimi i biletës. Ky quhet rasti i përdorimit.

Le të plotësojmë diagramin tonë me një vend për rastet e përdorimit.

Përdoruesit gjithashtu duhet t'i jepet mundësia për të tërhequr këto raste përdorimi dhe për të marrë rezultatin. Këto mund të jenë butona dhe elementë të tjerë grafikë hyrës-dalës, gjeste, njohje dhe sintezë e të folurit. Çdo opsion për shkëmbimin e të dhënave dhe komandave. Voila:

Përdoruesi tërheq disa nga rastet e përdorimit, të cilat, nga ana tjetër, manipulojnë programin. Programi publikon rezultatin ose ndryshimet në gjendjen e tij.

Pra, ku është MVC e njëjtë?

E tëra që mbetet është t'u japim emra të njohur përbërësve që rezultojnë.

Kur modeli publikon ndryshimet, nuk i intereson për kë, nuk di asgjë për View-n. Në vend të ose së bashku me View, mund të ketë një nënsistem tjetër në skajin tjetër.

Tani disa detaje.

Ishte një variant klasik MVC - Model Active. Ndodh gjithashtu që modeli të mos njoftojë për ndryshime. Pastaj kontrolluesi merr përsipër këtë përgjegjësi. Ai e di se çfarë lloj manipulimesh po i bën modeles dhe padyshim e di se çfarë ndryshimesh në gjendjen e modelit mund të pasojnë. Ky është modeli pasiv.

Dhe një moment. Ndarja e kodit në subjekt dhe jo subjekt është i kushtëzuar dhe varet nga sa pedant duam të modelojmë fushën e lëndës. Ndonjëherë është një vendim racional për të përfshirë disa raste përdorimi në model. Ndoshta kjo do të zvogëlojë sasinë e kodit në përgjithësi dhe do ta thjeshtojë atë.

Për materialin falënderojmë pajtimtarin tonë Stanislav Ilyichev