Ustvari mvc motor iz nič. MVC: kaj je in kako se nanaša na uporabniški vmesnik. Styling Thanks View

      Mnogi začnejo pisati projekt, ki bo deloval z eno samo nalogo, ne nakazujejo pa, da lahko preraste v več uporabniški sistem upravljanja, no, recimo, vsebine ali ne daj Bože, produkcije. In vse se zdi kul in kul, vse deluje, dokler ne začnete razumeti, da je napisana koda v celoti sestavljena iz ščetk in trde kode. Koda je mešana s postavitvijo, poizvedbami in ščetkami, včasih celo neberljivimi. Obstaja nujna težava: ko dodajate nove funkcije, se morate s to kodo dolgo časa spopadati in se spomniti, "kaj je bilo tam napisano?" in se preklinjaj v preteklosti.

Morda ste že slišali za vzorce oblikovanja in celo prelistali te čudovite knjige:

• E. Gamma, R. Helm, R. Johnson, J. Vlissides „Tehnike objektivnega oblikovanja. Oblikovanje vzorcev “;
• M. Fowler "Arhitektura aplikacij korporativne programske opreme."

  In mnogi, ki se ne bojijo ogromnih priročnikov in dokumentacije, so poskušali preučiti kateri koli od sodobnih okvirov in se soočili s težavo razumevanja (zaradi prisotnosti številnih arhitekturnih konceptov, ki jih umetniško povezujejo skupaj), so preložili preučevanje in uporabo sodobnih orodij v "dolgo škatlo".

Ta članek bo uporaben predvsem za začetnike. Vsekakor upam, da boste čez nekaj ur dobili predstavo o izvajanju vzorca MVC, ki je podlaga za vse sodobne spletne okvire, in dobili "hrano" za nadaljnje razmišljanje, kako to storiti. Na koncu članka je izbor uporabnih povezav, ki vam bodo pomagale tudi ugotoviti, kaj sestavljajo spletni okviri (razen MVC) in kako delujejo.

Trdojedni programerji PHP v tem članku verjetno ne bodo našli nič novega zase, vendar bi bili njihovi komentarji in komentarji k glavnemu besedilu zelo koristni! Ker brez teorije je praksa nemogoča in brez prakse je teorija neuporabna, potem bo najprej malo teorije, nato pa bomo prešli na prakso. Če že poznate koncept MVC, lahko preskočite teoretični odsek in greste naravnost na prakso.

1. Teorija

Vzorec MVC opisuje preprost način gradnje aplikacije aplikacije, katere namen je ločiti poslovno logiko od uporabniškega vmesnika. Zaradi tega je aplikacijo lažje spreminjati, preizkusiti, vzdrževati in seveda implementirati.

Razmislite o konceptualni shemi predloge MVC (po mojem mnenju je to najuspešnejša shema, ki sem jo videl):

V arhitekturi MVC model zagotavlja podatke in pravila poslovne logike, pogled je odgovoren za uporabniški vmesnik, krmilnik pa interakcijo med modelom in pogledom.

Značilno zaporedje aplikacije MVC lahko opišemo na naslednji način:

1. Ko uporabnik vstopi v spletni vir, inicializacijski skript ustvari primerek aplikacije in ga zažene za izvajanje.
     Prikaže se pogled, recimo glavna stran spletnega mesta.
2. Aplikacija prejme zahtevo od uporabnika in določi zahtevani krmilnik in dejanje. V primeru glavne strani se privzeto izvede dejanje ( kazalo).
3. Aplikacija ustvari primerek krmilnika in zažene način delovanja,
     ki na primer vsebuje klice modelov, ki berejo informacije iz baze podatkov.
4. Po tem dejanje oblikuje pogled s podatki, pridobljenimi iz modela in uporabniku prikaže rezultat.

Model   - vsebuje poslovno logiko aplikacije in vključuje metode izbire (to so lahko metode ORM), obdelavo (na primer pravila za potrjevanje) in zagotavljanje specifičnih podatkov, zaradi česar so pogosto zelo debeli, kar je povsem normalno.
  Model ne sme neposredno komunicirati z uporabnikom. Vse spremenljivke, povezane z zahtevo uporabnika, morajo biti obdelane v regulatorju.
  Model ne sme ustvarjati HTML ali druge prikazne kode, ki se lahko razlikuje glede na potrebe uporabnika. Takšno kodo je treba obdelati v pogledih.
  Na primer isti model: model za preverjanje pristnosti uporabnikov se lahko uporablja tako v uporabniškem kot v administrativnem delu aplikacije. V tem primeru lahko splošno kodo prevzamete v ločenem razredu in jo podedujete tako, da v dedičih določite metode, specifične za uporabo.

Pogled   - se uporablja za določanje zunanjega prikaza podatkov, prejetih od regulatorja in modela.
  Pogledi vsebujejo oznako HTML in majhne vstavke kode PHP za pajkanje, oblikovanje in prikaz podatkov.
  Ne bi smeli neposredno dostopati do baze podatkov. To bi moral storiti model.
  Ne sme delovati s podatki, pridobljenimi iz zahteve uporabnika. To nalogo mora opraviti krmilnik.
Lahko neposredno dostopa do lastnosti in metod krmilnika ali modelov, da pridobi podatke, pripravljene za izhod.
  Pogledi so običajno razdeljeni na skupno predlogo, ki vsebuje oznako, skupno za vse strani (na primer glavo in nogo), in dele predloge, ki se uporabljajo za prikaz izhodov podatkov iz modela ali prikaz obrazcev za vnos podatkov.

Krmilnik   - povezovalna povezava, ki povezuje modele, poglede in druge komponente v delujočo aplikacijo. Krmilnik je odgovoren za obdelavo uporabniških zahtev. Krmilnik ne sme vsebovati poizvedb SQL. Najbolje se obdržijo v modelih. Krmilnik ne bi smel vsebovati HTML-ja ali druge oznake. Dati bi ga bilo treba v vrste.
  V dobro zasnovani aplikaciji MVC so krmilniki običajno zelo tanki in vsebujejo le nekaj deset vrstic kode. No, ne morete reči o neumnih krmilcih maščob (SFC) v Joomla CMS. Logika krmilnika je dokaj tipična in večina se izvaja v osnovnih razredih.
  Nasprotno, modeli so zelo debeli in vsebujejo večino kode, povezane z obdelavo podatkov, ker Struktura podatkov in poslovna logika, ki ju vsebuje, sta ponavadi za določeno aplikacijo precej specifični.

1.1. Sprednji regulator in nadzornik strani

  V večini primerov interakcija uporabnika s spletno aplikacijo poteka s klikom na povezave. Poglejte zdaj v naslovno vrstico brskalnika - to besedilo ste dobili s te povezave. Druge povezave, na primer na desni strani te strani, bodo imele drugačno vsebino. Tako povezava predstavlja določen ukaz do spletne aplikacije.

Upam, da ste že uspeli opaziti, da imajo različna spletna mesta lahko povsem drugačne formate za gradnjo naslovne vrstice. Vsaka oblika lahko prikaže arhitekturo spletne aplikacije. Čeprav to ni vedno tako, je v večini primerov to jasno dejstvo.

Razmislite o dveh možnostih za naslovno vrstico, ki prikazuje nekaj besedila in uporabniškega profila.

Približna koda za obdelavo v tem primeru:
  stikalo ($ _ GET ["dejanje"]) (primer "približno": Requir_once ("about.php"); // stran "O nas" prelom; zadeva "kontakti": Requir_once ("Contacts.php"); // prekinitev strani s stiki; primer "povratne informacije": zahteva_once ("povratna informacija.php"); // prelom strani s povratnimi informacijami; privzeto: zahteva_once ("stran404.php"); // prekinitev strani "404";)
  Mislim, da so to počeli že prej skoraj vsi.

S pomočjo mehanizma za usmerjanje URL-jev lahko aplikacijo konfigurirate tako, da prejme naslednje zahteve za prikaz enakih informacij:
http://www.example.com/contacts/feedback

Tu so stiki krmilnik, povratne informacije pa metoda krmilnika stikov, ki prikazuje obrazec za povratne informacije itd. Na to vprašanje se bomo vrnili v praktičnem delu.

Prav tako je vredno vedeti, da usmerjevalniki številnih spletnih okvirov omogočajo ustvarjanje poljubnih URL poti (določite, kaj pomeni vsak del URL-ja) in pravila za njihovo obdelavo.
  Zdaj imamo dovolj teoretičnega znanja za nadaljevanje prakse.

2. Vadite

  Najprej ustvarite naslednjo strukturo datotek in map:

  Če pogledam naprej, bom rekel, da bodo jedrni razredi Model, View in Controller shranjeni v osnovni mapi.
  Njihovi potomci bodo shranjeni v režiserjevih nadzornikih, modelih in pogledih. Datoteka index.php   To je točka v napredku v aplikaciji. Datoteka bootstrap.php   sproži prenos aplikacije, poveže vse potrebne module itd.

Šli bomo zaporedno; odprite datoteko index.php in jo napolnite s to kodo:
  ini_set ("display_errors", 1); need_once "aplikacija / bootstrap.php";
  Tu se vprašanja ne bi smela pojaviti.

Nato gremo naravnost do halyarda bootstrap.php:
  need_once "jedro / model.php"; need_once "jedro / view.php"; need_once "jedro / controller.php"; need_once "jedro / route.php"; Pot :: start (); // zaženite usmerjevalnik
  Prve tri vrstice bodo vsebovale datoteke jedra, ki še ne obstajajo. Zadnje vrstice vključujejo datoteko z razredom usmerjevalnika in jo zaženejo s klicanjem metode statičnega zagona.

2.1. Izvajanje usmerjevalnika URL

  Zaenkrat se oddaljimo od izvajanja vzorca MVC in naredimo usmerjanje. Prvi korak, ki ga moramo narediti, je napisati naslednjo kodo .htaccess:
  RewriteEngine na RewriteCond% (REQUEST_FILENAME)! -F RewriteCond% (REQUEST_FILENAME)! -D RewriteRule. * Index.php [L]
  Ta koda bo preusmerila obdelavo vseh strani na index.php, kar potrebujemo. Se spomnite, v prvem delu smo govorili o Front Controllerju ?!

Usmerjenost bomo postavili v ločeno datoteko route.php   v osnovni imenik. V tej datoteki opisujemo razred Route, ki bo izvajal metode krmilnikov, kar bo posledično ustvarilo videz strani.

Vsebina datoteke route.php

razred Route (statična funkcija start () (// krmilnik in privzeto dejanje $ controller_name \u003d "Main"; $ action_name \u003d "index"; $ route \u003d eksplode ("/", $ _SERVER ["REQUEST_URI")) // dobite ime regulatorja, če (! prazno ($ route)) ($ controller_name \u003d $ route;) // dobite ime dejanja, če (! prazno ($ route)) ($ action_name \u003d $ route;) // dodajte predpono $ model_name \u003d " Model _ ". $ Controller_name; $ controller_name \u003d" Controller _ ". $ Controller_name; $ action_name \u003d" action _ ". $ Action_name; // prikličite datoteko z modelom razreda (datoteka modela morda ne obstaja) $ model_file \u003d strtolower ($ model_name). ".php"; $ model_path \u003d "aplikacija / modeli /".$ model_file; if (file_exists ($ model_path)) (vključuje" application / models /".$ model_file;) // priklopite datoteko s krmilnim razredom $ controller_file \u003d strtolower ($ nadzor ler_name). ". php"; $ controller_path \u003d "aplikacija / krmilniki /".$ controller_file; if (datoteka_obstaja ($ controller_path)) (vključuje" application / controllers /".$ controller_file; ) else (/ * bi bilo pravilno, da bi tukaj vrgli izjemo, a zaradi preprostosti bomo takoj preusmerili na stran 404 * / Route :: ErrorPage404 ();) // ustvarili krmilnik $ controller \u003d new $ controller_name; $ action \u003d $ action_name; if (method_exists ($ kontroler, $ action)) (// pokličite dejanje krmilnika $ controller -\u003e $ action ();) else (// tudi bolj smiselno bi bilo vrziti izjemo funkcija Route :: ErrorPage404 ();)) ErrorPage404 ( ) ($ host \u003d "http: //". $ _ SERVER ["HTTP_HOST"]. "/"; header ("HTTP / 1.1 404 ni mogoče najti"); header ("Status: 404 not found"); header (" Lokacija: ". $ Gostitelj." 404 ");))

  Opažam, da razred izvaja zelo poenostavljeno logiko (kljub obsežni kodi) in ima morda celo težave z varnostjo. To je bilo storjeno namerno, ker pisanje polnopravnega razreda usmerjanja si zasluži vsaj ločen članek. Razmislite o glavnih točkah ...

Element globalnega niza $ _SERVER ["REQUEST_URI"] vsebuje celoten naslov, do katerega je uporabnik dostopal.
  Na primer: example.ru/contacts/feedback

Uporaba funkcije eksplodirati   naslov je razdeljen na komponente. Kot rezultat dobimo ime regulatorja, za dani primer je to krmilnik stikov   in ime akcije, v našem primeru - povratne informacije.

Nato je povezana datoteka modela (model je morda odsoten) in datoteka krmilnika, če obstaja, in na koncu se ustvari primerek krmilnika in znova pokliče dejanje, če je bilo opisano v razredu regulatorja.

Tako na primer na naslov:
example.com/portfolio
  ali
example.com/portfolio/index
  usmerjevalnik bo naredil naslednje:

1. vključite datoteko model_portfolio.php iz mape modelov, ki vsebuje razred Model_Portfolio;
2. povežite datoteko controller_portfolio.php iz mape regulatorjev, ki vsebuje razred Controller_Portfolio;
3. bo ustvaril primerek razreda Controller_Portfolio in poklical privzeto dejanje - action_index, opisano v njem.

  Če se uporabnik poskuša obrniti na naslov neobstoječega krmilnika, na primer:
example.com/ufo
  potem bo preusmerjen na stran "404":
example.com/404
  Enako se zgodi, če uporabnik dostopa do dejanja, ki ni opisano v regulatorju.

2.2. Nazaj na izvedbo MVC

  Pojdite v osnovno mapo in dodajte še tri datoteke v datoteko route.php: model.php, view.php in controller.php

  Naj vas spomnim, da bodo vsebovali osnovne razrede, o katerih bomo zdaj začeli pisati.

Vsebina datoteke model.php
  Model razreda (javna funkcija get_data () ())
  Modelni razred vsebuje edino prazno metodo izbire podatkov, ki se bo prekrivala v potomcih. Ko bomo ustvarili potomce, bo vse bolj jasno.

Vsebina datoteke view.php
  Pogled razreda (// javni $ template_view; // tu lahko določite splošni privzeti pogled. funkcija generira ($ content_view, $ template_view, $ data \u003d null) (/ * if (is_array ($ data)) (// pretvori elemente matrike v ekstrakt spremenljivk ($ data);) * / vključi "application / views /".$ template_view;))
  Kakšna metoda ni težko uganiti ustvarjati   Zasnovan za oblikovanje pogleda. Naslednji parametri so mu posredovani:

1. $ content_file - pogledi, ki prikazujejo vsebino strani;
2. $ template_file - skupna predloga za vse strani;
3. $ data je matrika, ki vsebuje elemente vsebine strani. Običajno se poseli po modelu.

  Funkcija vključi dinamično poveže skupno predlogo (pogled), znotraj katere bo pogled vgrajen
  za prikaz vsebine določene strani.

V našem primeru bo splošna predloga vsebovala glavo, meni, stransko vrstico in nogo, vsebina strani pa bo v ločeni obliki. Spet se to naredi zaradi preprostosti.

Vsebina datoteke controller.php
  kontroler razreda (javni $ model; javni $ pogled; funkcija __construct () ($ to-\u003e pogled \u003d nov pogled ();) funkcija action_index () ())
  Metoda action_index   - to je privzeto dejanje; prevladali bomo pri izvajanju razredov potomcev.

2.3. Izvajanje otroških razredov Model in krmilnik, ustvarjanje View "s

Zdaj se zabava začne! Naše spletno mesto za vizitke bo sestavljeno iz naslednjih strani:

1. Domov
2. Storitve
3. Portfelj
4. Kontaktni podatki
5. In tudi - stran "404"

  Vsaka stran ima svoj krmilnik iz mape regulatorjev in pogled iz mape pogledi. Nekatere strani lahko uporabljajo model ali modele v mapi modelov.

  Na prejšnji sliki je datoteka posebej poudarjena template_view.php   - To je predloga, ki vsebuje skupno oznako za vse strani. V najpreprostejšem primeru bi lahko izgledalo tako:

  Da bi spletno mesto izgledalo predstavljivo, sestavimo predlogo CSS in jo vključimo v svoje spletno mesto s spreminjanjem strukture označevanja HTML in povezovanjem datotek CSS in JavaScript:

  Na koncu članka je v razdelku »Rezultat« povezava do skladišča GitHub s projektom, v katerem so bili sprejeti koraki za vključitev preproste predloge.

2.3.1. Ustvari domačo stran

  Začnimo s krmilnikom controller_main.php, tukaj je njegova koda:
  razred Controller_Main podaljša Controller (funkcija action_index () ($ this-\u003e view-\u003e generator ("main_view.php", "template_view.php");))
  V metodi ustvarjati   primerek razreda Pogled prenaša imena datotek splošne predloge in si jih ogleduje z vsebino strani.
  Poleg indeksnega dejanja lahko krmilnik seveda vsebuje tudi druga dejanja.

Prej smo datoteko pregledali s splošnim pogledom. Razmislite o datoteki z vsebino main_view.php:

Dobrodošli

  OLAMOS TEAM - skupina vrhunskih strokovnjakov za razvoj spletnih strani z dolgoletnimi izkušnjami, ki zbirajo mehiške maske, bronaste in kamnite kipe iz Indije in Celona, \u200b\u200bbareljeve in skulpture, ki so jih pred petimi in šestimi stoletji ustvarili mojstri iz ekvatorialne Afrike ...

  Vsebuje preprosto označevanje brez klicev PHP.
  Za prikaz glavne strani lahko uporabite enega od naslednjih naslovov:

  Primer uporabe pogleda, ki prikazuje podatke, pridobljene iz modela, bomo obravnavali pozneje.

2.3.2. Ustvari stran s portfeljem

  V našem primeru je stran z portfeljem edina stran, ki uporablja model.
  Model običajno vključuje metode vzorčenja podatkov, na primer:

1. metode izvorne knjižnice pgsql ali mysql
2. metode knjižnic, ki izvajajo odvzem podatkov. Na primer metode knjižnice PEAR MDB2;
3. oRM metode
4. metode za delo z NoSQL;
5. in drugi

  Za preprostost tu ne bomo uporabljali poizvedb SQL ali stavkov ORM. Namesto tega posnemamo resnične podatke in takoj vrnemo niz rezultatov.
  Modelna datoteka model_portfolio.php   daj v mapo modelov. Tu je njegova vsebina:
razred Model_Portfolio razširja Model (javna funkcija get_data () (matrika vrnitve (array ("Leto" \u003d\u003e "2012", "Spletna stran" \u003d\u003e "http://DunkelBeer.ru", "Opis" \u003d\u003e "Temno promocijsko mesto) Dunkel pivo nemškega proizvajalca Löwenbraü, ki ga v Rusiji proizvaja pivovarna CAN InBev. "), Array (" Year "\u003d\u003e" 2012 "," Site "\u003d\u003e" http://ZopoMobile.ru "," Opis "\u003d\u003e "Ruski jezik kataloga kitajskih telefonov Zopo, ki temelji na operacijskem sistemu Android in njihovih dodatkih."), // todo);))

Razred krmilnika modela je v datoteki controller_portfolio.php, tukaj je njegova koda:
  razred Controller_Portfolio razširja Controller (funkcija __construct () ($ this-\u003e model \u003d nov Model_Portfolio (); $ this-\u003e view \u003d new View ();) funkcija action_index () ($ data \u003d $ this-\u003e model-\u003e get_data ( ); $ this-\u003e view-\u003e create ("portfolio_view.php", "template_view.php", $ data);))
  Do spremenljivke podatkov   zapiše se matrika, ki jo vrne metoda get_datao čemer smo že prej razmišljali.
  Ta spremenljivka se nato posreduje kot parameter metodi. ustvarjati, na katero se prenesejo tudi: ime datoteke s skupno predlogo in ime datoteke, ki vsebuje pogled z vsebino strani.

Pogled, ki vsebuje vsebino strani, je v datoteki portfolio_view.php.

Portfelj

  Vsi projekti v naslednji razpredelnici so izmišljeni, zato niti ne poskušajte slediti priloženim povezavam. "; } ?>

Leto	Projekt	Opis
". $ row [" Leto "]."	". $ row [" Spletna stran "]."	". $ row [" Opis "]."

  Tu je vse preprosto, pogled prikazuje podatke, pridobljene iz modela.

2.3.3. Ustvarite preostale strani

  Preostale strani so ustvarjene na enak način. Njihova koda je na voljo v repozitoriju GitHub, povezava do nje je na koncu članka, v razdelku "Rezultat".

3. Rezultat

  In tu je rezultat:

Posnetek zaslona spletnega mesta o vizitki

  Povezava GitHub: https://github.com/vitalyswipe/tinymvc/zipball/v0.1

Toda v tej različici sem skiciral naslednje razrede (in ustrezne vrste):

• Controller_Login, pri katerem se ustvari pogled z obrazcem za vnos prijave in gesla, po izpolnitvi, ki se opravi postopek overjanja, in če je uspešen, se uporabnik preusmeri na skrbniško ploščo.
• Contorller_Admin z indeksnim dejanjem, v katerem preveri, ali je bil uporabnik na spletnem mestu predhodno pooblaščen za skrbnika (če je bil, potem je prikazan skrbniški pogled) in z odjavno akcijo, da se odjavi.

  Preverjanje pristnosti in avtorizacija sta različni temi, zato se tu ne obravnava, ampak je navedena samo zgoraj navedena povezava, tako da je treba nekaj začeti.

4. Sklep

Predloga MVC se uporablja kot arhitekturna osnova v mnogih okvirih in CMS, ki so bili ustvarjeni, da bi lahko v krajšem času razvili kakovostno bolj zapletene rešitve. To je bilo mogoče s povečanjem stopnje abstrakcije, saj je meja zahtevnosti struktur, na katerih lahko delujejo človeški možgani.

Toda uporaba spletnih okvirov, kot sta Yii ali Kohana, sestavljenih iz več sto datotek, pri razvoju preprostih spletnih aplikacij (na primer spletnih mest za vizitke) ni vedno priporočljiva. Zdaj lahko ustvarimo čudovit model MVC, da ne bi v eni datoteki mešali Php, Html, CSS in JavaScript kode.

Ta članek je bolj izhodišče za učenje CMF kot primer nečesa resnično pravilnega, kar lahko vzamete kot osnovo za svojo spletno aplikacijo. Morda vas je celo navdihnila in že razmišljate, da bi napisali svoj mikrookvir ali CMS na osnovi MVC-ja. Toda preden si izmislite drugo kolo z blackjackom in kurbami, premislite še enkrat, ali je pametneje usmeriti svoja prizadevanja v razvoj in pomoč skupnosti obstoječega projekta ?!

P.S .: Članek je bil ponovno napisan ob upoštevanju nekaterih komentarjev, ki so jih napisali v komentarjih. Kritika je bila v veliko pomoč. Sodeč po odzivu: komentarji, pritožbe v PM in število uporabnikov, ki so dodali objavo na vašo najljubšo idejo, da napišete to objavo, ni bilo tako slabo. Žal zaradi želje zaradi pomanjkanja časa ni mogoče upoštevati vseh želja in podrobneje pisati podrobneje ... morda pa bodo to naredili tisti skrivnostni posamezniki, ki so minus originalno različico. Vso srečo s svojimi projekti!

5. Izbor uporabnih povezav za zadevo

  Članek se zelo pogosto dotika teme spletnih okvirov - to je zelo obsežna tema, saj celo mikroframi sestavljajo številne komponente, ki so umetniško povezane, in bi o teh komponentah potrebovali več člankov. Kljub temu sem se odločil, da bom tukaj navedel majhen izbor povezav (ki sem jim sledil med pisanjem tega članka), ki se tako ali drugače nanašajo na temo okvirov.

Oznake:

• php
• ogrodje
• cmf
• mvc
• spletnega mesta

   Dodajte oznake

Pozdravljeni vsi! Še naprej gradimo svoje MVC aplikacijain danes se bomo začeli ukvarjati z izhodom strani.

Ustvari datoteko View.php   v mapi uši.

   Pogled razreda (

   odmev "To je pogled";
}
}
?>

Zdaj odprite našo glavno datoteko index.php   in ga povežite.

Zahtevaj "libs / View.php";

Ko smo odprli stran, bi morali videti napis "To je pogled."

Zdaj pa spremenimo naš razred ogledov z dodajanjem metode upodabljajokdo se bo ukvarjal s sklepom.

   Pogled razreda (
   javna funkcija __construct () (
   odmev "To je pogled";
}

Prikazovanje javnih funkcij ($ name) (
   zahtevajo "poglede /".$ ime.". php ";
}
}
?>

Zdaj ustvarite mape kazalo   in napaka   v mapi pogledi. Odgovorni bodo za oddajo. kazalo   strani in strani z napakami. V mapi napaka   ustvari novo index.php   datoteko in napišite naslednje

  To je stran z napako!

Zdaj ustvarite datoteko header.php   v sami mapi pogledi   s takšno vsebino

  Glava

Pojdimo k spisu error.phpki se nahaja v mapi napaka   in konstruktorju dodate klic metode upodabljajo.

   javna funkcija __construct () (
   // koda
   $ this-\u003e view-\u003e render ("napaka / indeks");
}
?>

Zdaj na strani bomo videli "Glava To je stran o napaki!"

Naj nekoliko izboljšamo naš krmilnik, tako da ga dodamo pred klicanjem metode upodabljajo   naslednje:

   javna funkcija __construct () (
   // koda
   $ this-\u003e view-\u003e msg \u003d "Stran ne obstaja!";
   $ this-\u003e view-\u003e render ("napaka / indeks");
}
?>

In zdaj v spisu index.php, ki je odgovoren za vrsto napake, namesto našega napisa "To je stran z napako!" natisnite tisto, kar je shranjeno v znamki msg.

---

msg; ?\u003e

Zdaj smo dobili naš napis.

Ustvarimo model zdaj help_model.php   v mapi modelov.

   Razred Help_Model podaljša model (
   javna funkcija __construct () (
   odmev "Model help_model";
}
}
?>

Zdaj odprite regulator help.php   iz mape krmilniki   in dodajte klic v naš model

   Pomoč razreda razširi krmilnik (
   // koda

Javna funkcija drugo ($ arg \u003d false) (
   // koda

Zahtevaj "modele / help_model.php";
   $ model \u003d nov Help_Model ();
}
}
?>

   razred razreda (
   javna funkcija __construct () (
   // $ this-\u003e baza podatkov \u003d nova zbirka podatkov ();
}
}
?>

Naš model bo deloval z bazo podatkov, vendar za zdaj to komentirajte, ker podatkovne baze še nimamo.

V našo glavno datoteko povežite osnovni model index.php.

Zahtevaj "libs / Bootstrap.php"; zahtevajo "libs / Controller.php"; zahtevajo "libs / model.php"; zahtevajo "libs / View.php";

Torej, danes se ustavimo pri tem. Na strani smo že naredili nekaj zaključkov, v prihodnjih člankih pa bomo to še izboljševali. Hvala za vašo pozornost in dobro kodiranje!

Oblika oblikovanja Controller-View-Controller (MVC)   Je predloga za arhitekturo programske opreme, zgrajena na podlagi ohranjanja predstavitve podatkov ločeno od metod, ki vplivajo na podatke.

Kljub temu, da je bila shema MVC prvotno razvita za osebne računalnike, je bila prilagojena in jo pogosto uporabljajo spletni razvijalci zaradi natančne diferenciacije nalog in možnosti ponovne uporabe kode. Shema spodbuja razvoj modularnih sistemov, ki razvijalcem omogoča hitro posodobitev, dodajanje ali odstranjevanje funkcionalnosti.

V tem članku bom opisal osnovna načela, upošteval pa bom tudi definicijo konstrukcijske sheme in preprost primer MVC PHP.

Kaj je MVC?

Ime oblikovalskega vzorca določajo tri glavne komponente: Model, Pogled in Krmilnik. Vizualna predstavitev predloge MVC je videti, kot je prikazano na sliki spodnji grafikon:

  Slika prikazuje strukturo enosmernega pretoka podatkov in njegovo pot med različnimi komponentami ter njihovo interakcijo.

Model

Model se imenuje trajno shranjevanje podatkov, ki se uporabljajo v celotni strukturi. Zagotoviti mora dostop do podatkov za ogled, izbiro ali snemanje. V celotni strukturi je model most med komponentami View in Controller.

Hkrati "Model" nima povezave ali informacij o tem, kaj se zgodi s podatki, ko se posredujejo komponentam "View" ali "Controller". Edina naloga "modela" je obdelava podatkov v trajnem shranjevanju, iskanje in priprava podatkov, poslanih drugim komponentam MVC.

"Model" naj deluje kot "vratar", ki stoji v bližini podatkovnega skladišča in ne postavlja vprašanj, ampak sprejema vse prispele zahteve. To je pogosto najkompleksnejši del sistema MVC. Sestavni del „Model“ je vrhunec celotne strukture, saj brez njega povezava med „Krmilnikom“ in „Pogledom“ ni mogoča.

Oddaja

Pogled je del sistema, v katerem so podatki, ki jih zahteva model, postavljeni v končno obliko njihovega izhoda. V spletnih aplikacijah, ki temeljijo na MVC, je »View« komponenta, v kateri se ustvarja in prikazuje HTML.

Pogled zajame tudi uporabniško dejanje, ki se nato posreduje Krmilniku. Tipičen primer tega je gumb, ki ga ustvari Pogled. Ko uporabnik klikne, se zažene dejanje v "Krmilniku".

V zvezi s komponento predstavitve obstaja več pogostih napačnih predstav. Na primer, mnogi zmotno menijo, da "Pogled" nima povezave z "Model", vsi prikazani podatki pa se prenašajo iz "Krmilnika". Pravzaprav takšna shema pretoka podatkov ne upošteva teorije, ki temelji na arhitekturi MVC. Fabio Chevasko v svojem članku opisuje ta napačen pristop z uporabo enega od nekonvencionalnih okvirov MVC PHP kot primer:

"Za pravilno uporabo arhitekture MVC ne sme biti interakcije med" Model "in" View ": vso logiko obdela" Controller ".

Poleg tega je tudi definicija pojma kot datoteke predloge prav tako napačna. Vendar za to ni kriv en človek, ampak rezultat številnih napak različnih razvijalcev, ki vodijo do pogoste napačne predstave. Nato jih napačno razložijo drugim. Pravzaprav je "Pogled" veliko več kot le predloga. Toda sodobni okviri, usmerjeni v MVC, so ta pristop absorbirali do te mere, da nikogar ni briga, ali je pravilna struktura MVC podprta ali ne.

Nadzornik nikoli ne pošlje komponente View. Med "Pogledom" in "Krmilnikom" ni neposredne povezave - povezani sta z modelom "Model".

Krmilnik

Njegova naloga je obdelati podatke, ki jih uporabnik vnese in posodobiti "Model". To je edini del vezja, ki zahteva interakcijo uporabnika.

"Krmilnik" je mogoče opredeliti kot zbiralec informacij, ki se nato prenese v "Model" z naknadno organizacijo za shranjevanje. Ne vsebuje nobene druge logike, razen potrebe po zbiranju vhodnih podatkov. "Krmilnik" je povezan tudi samo z enim "Pogledom" in enim "modelom". Tako se ustvari sistem z enosmernim tokom podatkov z enim vhodom in enim izhodom na mestih izmenjave podatkov.

"Krmilnik" prejme naloge za izvedbo samo, ko uporabnik sodeluje s "Pogledom", vsaka funkcija pa je odvisna od interakcije uporabnika z "Pogledom". Najpogostejša napaka, ki so jo naredili razvijalci, je, da "Krmilnik" zamenjajo z prehodom, zato jim dodeljujejo funkcije in naloge, ki se nanašajo na "Pogled".

Druga pogosta napaka je, da „Krmilnik“ podelite funkcije, ki so odgovorne samo za obdelavo in prenos podatkov iz „Modela“ v „Pogled“. Glede na strukturo vzorca MVC pa naj bi bila ta interakcija med "modelom" in "pogledom".

MVC v PHP

V PHP bomo napisali spletno aplikacijo, katere arhitektura temelji na MVC. Začnimo s primerom žičnega okvira:

string \u003d "MVC + PHP \u003d Super!"; )))regulator \u003d $ regulator; $ this-\u003e model \u003d $ model; ) javni funkcijski izhod () (vrnitev "

". $ this-\u003e model-\u003e niz."

"; } } model \u003d $ model; )))

Za vsak del predloge imamo projekt z več glavnimi razredi. Zdaj morate nastaviti povezavo med njimi:

izhod ();

V zgornjem primeru PHP MVC za krmilnik ni določene funkcionalnosti, ker interakcije uporabnikov v aplikaciji niso definirane. Pogled vsebuje vso funkcionalnost, saj je naš primer namenjen samo demonstraciji.

Razširimo primer, da pokažemo, kako bomo dodali funkcionalnost krmilnika in s tem dodali interakcije v aplikacijo:

string \u003d "MVC + PHP \u003d Super, kliknite tukaj!"; )))regulator \u003d $ regulator; $ this-\u003e model \u003d $ model; ) javni funkcijski izhod () (vrnitev "

model-\u003e string "

"; } } model \u003d $ model; ) javna funkcija je kliknila () ($ this-\u003e model-\u003e string \u003d "Posodobljeni podatki, zahvaljujoč MVC in PHP!";))

Program smo razširili z osnovno funkcionalnostjo. Vzpostavitev interakcij med komponentami zdaj izgleda tako:

($ _GET ["dejanje"]) (); ) echo $ view-\u003e output ();

Pozdravljeni vsi! Danes pišem prvi članek v seriji, namenjen ustvarjanju svojega MVC aplikacije.

Najprej je treba opozoriti, da če kdo ne ve, kaj je MVCnato najprej preberite ta članek:.

Kaj bomo torej imeli na koncu? Imeli bomo motorustvarjeno z uporabo vzorec oblikovanja MVC. Ta motor bo zelo preprost, preverjanja bodo nekje izpuščena, vendar je to vse narejeno tako, da razumete, kako ustvarjati aplikacije MVC, nato pa, ko dokončno oblikujete naš motor, ga lahko uporabite za svoje projekte. Imeli bomo osnovno funkcionalnost:

• pooblastilo
• majhen klepet
• dodajanje člankov
• urejanje članka
• brisanje člankov
• upravljanje uporabnikov

Vse se začne s strukturo mape. Imeli ga bomo tako:

• index.php
• .htaccess
• krmilniki
• modelov
• pogledi
• uši

Mislim, da je tukaj vse jasno. V mapah krmilniki, modelov, pogledi   in uši   se bodo obdržali krmilniki, modelov, vrste   in druge datoteke. V procesu ustvarjanja bomo dodali mape in datoteke, ki jih potrebujemo.

Za ustvarjanje bo uporabljen naš motor objektno usmerjen pristop. Če ga ne poznate dobro, potem o tem članku najprej preberite tudi na spletnem mestu.

Tukaj zaključujem uvodni članek in v naslednjem bomo začeli ustvarjati mVC motor. Se vidimo kmalu!

Vzorec Controller-View-Controller (MVC), ki je bila odprta v poznih sedemdesetih letih prejšnjega stoletja, je vzorec oblikovanja arhitekture programske opreme, katere glavna naloga je ločiti podatkovne funkcije od njihove predstavitve. Teoretično, dobro zasnovana aplikacija MVC bo razvijalcem sprednjega in zadnjega dela med delom ne omogočila, da se med delom ne vmešavajo v področja odgovornosti, torej razvijalcu ne bo treba vedeti ničesar o "kuhinji" svojega zalednega kolega in obratno.

Čeprav je bil MVC prvotno zasnovan za razvoj namiznih aplikacij, je bil prilagojen sodobnim nalogam in je zelo priljubljen med spletnimi razvijalci, saj je zaradi delitve odgovornosti postalo mogoče ustvariti bolj jasno, že pripravljeno kodo. Vzorec MVC vodi do jasnih modularnih sistemov, ki razvijalcem omogočajo, da zelo hitro spremenijo obstoječo kodo.

V tem članku bomo obravnavali osnovna načela MVC, začenši z določitvijo vzorca in nadaljevanjem z njegovo uporabo v majhnem primeru. Ta članek bo koristen predvsem tistim, ki se v življenju še nikoli niso srečali s tem vzorcem, morda pa tudi tistim, ki želijo osvežiti svoje znanje o MVC.

Razumevanje MVC

Kot je bilo že omenjeno, ime vzorca izvira iz kratice treh besed: Model Pogled   in Krmilnik. Na kratko lahko načelo vzorca ponazorimo po eni shemi (najdete ga na Wikipediji):

Ta diagram prikazuje enosmerni pretok informacij v vzorcu in opisuje tudi vloge vsake komponente.

Model

Model se uporablja za dostop in obdelavo podatkov. V večini primerov je model tisti, ki se uporablja za dostop do shrambe podatkov (na primer do baze podatkov). Model ponuja vmesnik za iskanje podatkov, njegovo ustvarjanje, spreminjanje in odstranjevanje iz skladišča. V okviru vzorca MVC model posreduje med pogledom in regulatorjem.

Izjemno pomembna lastnost modela je, da tehnično nima nobenega znanja o tem, kaj se zgodi s podatki v krmilniku in pogledu. Model nikoli ne sme vložiti ali pričakovati zahtevkov do / od drugih komponent vzorca.

Vedno pa ne pozabite, da model ni samo prehod za dostop do baze podatkov ali drugega sistema, ki se ukvarja samo s prenosom podatkov naprej in nazaj. Model je malo podatkovne točke. Model je v večini primerov najbolj zapleten del sistema, deloma tudi zaradi dejstva, da je sam model povezovalni člen za vse ostale dele.

Oddaja

Pogled je, kje se podatki, prejeti iz modela, prikažejo v želeni obliki. V tradicionalnih spletnih aplikacijah, razvitih kot del vzorca MVC, je predstavitev del sistema, v katerem se ustvarja HTML. Pogled je odgovoren tudi za sprejemanje dejanj od uporabnika, da jih pošlje krmilniku. Pogled na primer prikaže gumb v uporabniškem vmesniku in po pritisku pokliče ustrezno dejanje krmilnika.

Obstaja nekaj napačnih predstav glede namena predstavitve, zlasti med spletnimi razvijalci, ki šele začnejo graditi svoje aplikacije z uporabo MVC. Eno najpogosteje kršenih pravil je to predstavitev nikakor ne bi smela komunicirati z modelomin vse podatki, ki jih je pogled prejel, naj bi prišli le od upravljavca. V praksi razvijalci pogosto prezrejo ta koncept, ki leži v središču vzorca MVC. Članek Fabija Cevasco ponazarja ta zmeden pristop MVC z okvirom CakePHP, ki je eden izmed mnogih nestandardnih okvirov MVC:

Nujno je razumeti, da za pridobitev prave arhitekture MVC ne bi smeli biti neposrednih interakcij med pogledi in modeli. Vsa logika izmenjave podatkov med njimi mora biti izvedena v regulatorjih.

Poleg tega obstaja pogosta napačna predstava, da je pogled samo datoteka predloge. Kot je opozoril Tom Butler, ima ta napačna predstava ogromen obseg zaradi dejstva, da mnogi razvijalci že od samega začetka napačno razumejo strukturo MVC-ja, nakar začnejo to znanje vlivati \u200b\u200bnaprej, množice začetnikov razvijalcev. Pravzaprav je predstavitev veliko več kot le predloga, vendar so številni okviri, zgrajeni na podlagi vzorca MVC, popačili koncept predstavitve toliko, da nikogar ne zanima, kako pravilne so njihove aplikacije z vidika vzorca MVC.

Druga pomembna točka je, da pogled nikoli ne deluje s "čistimi" podatki krmilnika, to pomeni, da regulator nikoli ne deluje s pogledom, ki obide model. V procesu interakcije med krmilnikom in ogledom mora biti model vedno med njima.

Krmilnik

Krmilnik je zadnji del svežnja MVC. Naloga regulatorja je, da od uporabnika pridobi podatke in manipulira z modelom. Krmilnik in samo on je tisti del sistema, ki deluje z uporabnikom.

Na kratko, lahko je krmilnik opisan kot zbiralec informacij in ga posreduje modelu za obdelavo in shranjevanje. S podatki ne bi smel storiti ničesar, temveč jih je lahko le od uporabnika. Krmilnik je povezan z enim pogledom in enim modelom, s čimer organizira enosmerni tok podatkov in ga nadzoruje na vsaki stopnji.

Zelo pomembno je zapomniti, da krmilnik začne svoje delo le kot rezultat interakcije uporabnika s pogledom, ki pokliče ustrezno funkcijo regulatorja. Najpogostejša napaka razvijalcev je, da se krmilnik obravnava zgolj kot prehod med pogledom in modelom. Kot rezultat, je krmilnik obdarjen s tistimi funkcijami, ki jih mora opravljati pogled (mimogrede, od tod prihajajo noge ideje, da je pogled le datoteka predloge). Poleg tega mnogi na splošno odpravijo celotno logiko obdelave podatkov, pri čemer pozabijo, za kaj gre v vzorcu MVC.

MVC v PHP

Predlagam, da poskusite zgoraj navedeno poskusiti v majhni aplikaciji. Začnimo z ustvarjanjem razredov modela, pogleda in regulatorjev:

string \u003d "MVC + PHP \u003d Super!"; )))regulator \u003d $ regulator; $ this-\u003e

". $ this-\u003e model-\u003e niz."

"; } } model \u003d $ model; )))

Osnovni razredi so pripravljeni. Zdaj jih povežemo in zaženimo našo aplikacijo:

izhod ();

Kot vidite, krmilnik nima nobene funkcionalnosti, saj uporabnik ne komunicira z aplikacijo. Vsa funkcionalnost je postavljena na pogled, saj je naša aplikacija zasnovana izključno za izpis podatkov.

Aplikacijo nekoliko razširimo tako, da dodamo malo interaktivnosti, da vidimo, kako deluje krmilnik:

string \u003d "MVC + PHP \u003d Super, kliknite tukaj!"; )))regulator \u003d $ regulator; $ this-\u003e model \u003d $ model; ) javni funkcijski izhod () (vrnitev "

model-\u003e string "

"; } } model \u003d $ model; ) javna funkcija je kliknila () ($ this-\u003e model-\u003e string \u003d "Posodobljeni podatki, zahvaljujoč MVC in PHP!"))

In končno bomo nekoliko nadgradili vmesno programsko opremo:

($ _GET ["dejanje"]) (); ) echo $ view-\u003e output ();

Povzetek

V tem kratkem članku smo preučili osnovne koncepte oblikovalskega vzorca MVC in na osnovi njega razvili preprosto aplikacijo, čeprav smo tega še vedno zelo daleč od uporabe v resničnem življenju. V naslednjem članku bomo preučili glavne težave, s katerimi se boste srečali, če boste bolj tesno sodelovali pri gradnji arhitekture aplikacije na podlagi vzorca MVC. Ne pozabite!