Võib-olla olete isegi disainimustrite kohta kuulnud ja isegi neid imelisi raamatuid lehitsenud:
- E. Gamma, R. Helm, R. Johnson, J. Vlissides “Objektiivsed tehnikad orienteeritud disain. Kujundusmustrid";
- M. Fowler "Ettevõtte tarkvararakenduste arhitektuur".
See artikkel on kasulik eelkõige algajatele. Igal juhul loodan, et saate paari tunni pärast aimu kõigi kaasaegsete veebiraamistike aluseks oleva MVC mustri rakendamisest ning saate ka “toitu” edasiseks mõtisklemiseks teemal “kuidas tee seda." Artikli lõpus on valik Kasulikud lingid, mis aitab teil mõista, millest veebiraamistikud koosnevad (peale MVC) ja kuidas need töötavad.
Tõenäoliselt ei leia kogenud PHP programmeerijad sellest artiklist enda jaoks midagi uut, kuid nende kommentaarid ja kommentaarid põhiteksti kohta oleksid suureks abiks! Sest Ilma teooriata on praktika võimatu ja ilma praktikata on teooria kasutu, siis tuleb kõigepealt natuke teooriat ja siis liigume edasi praktika juurde. Kui olete MVC kontseptsiooniga juba tuttav, võite teooriaosa vahele jätta ja minna otse praktika juurde.
1. Teooria MVC muster kirjeldab lihtsat viisi rakenduse struktureerimiseks, mille eesmärk on eraldada äriloogika kasutajaliidest. Tänu sellele on rakendust lihtsam skaleerida, testida, hooldada ja loomulikult juurutada.Vaatame MVC mustri kontseptuaalset diagrammi (minu arvates on see kõige edukam diagramm, mida olen näinud):
Arhitektuuris MVC mudel annab andmeid ja äriloogika reegleid, mille eest vastutab vaade kasutajaliides ja kontroller pakub mudeli ja vaate vahelist suhtlust.
MVC-rakenduse tüüpilist voogu saab kirjeldada järgmiselt.
See kuvab näiteks saidi avalehe vaate.
mis sisaldab näiteks mudelikutseid, mis loevad andmebaasist infot.
Mudel ei tohiks kasutajaga otseselt suhelda. Kõik kasutaja päringuga seotud muutujad tuleb töödelda kontrolleris.
Mudel ei tohiks genereerida HTML-i ega muud kuvatavat koodi, mis võib muutuda olenevalt kasutaja vajadustest. Sellist koodi tuleks töödelda vaadetes.
Sama mudel näiteks: kasutaja autentimise mudelit saab kasutada nii rakenduse kasutaja- kui ka haldusosas. Sel juhul võib seda võtta üldine kood eraldi klassi ja pärida sellest, määratledes selle järglaste alamrakendustele omased meetodid.
Vaade – kasutatakse kontrollerilt ja mudelilt saadud andmete välise kuva määramiseks.
Vaated sisaldavad HTML-märgistust ja väikeseid PHP-koodi sisestusi andmete läbimiseks, vormindamiseks ja kuvamiseks.
Ei tohiks otse andmebaasi juurde pääseda. Seda peaksid mudelid tegema.
Ei tohiks töötada kasutaja päringu alusel saadud andmetega. Seda ülesannet peab täitma kontroller.
Saab otse juurde pääseda kontrolleri või mudelite atribuutidele ja meetoditele, et saada väljundvalmis andmeid.
Vaated jagunevad tavaliselt ühiseks malliks, mis sisaldab kõikidele lehtedele ühist märgistust (näiteks päis ja jalus) ning malli osi, mida kasutatakse mudelist väljastavate andmete kuvamiseks või andmesisestusvormide kuvamiseks.
Kontroller on liim, mis ühendab mudelid, vaated ja muud komponendid töötav rakendus. Vastutav töötleja vastutab kasutajate päringute töötlemise eest. Kontroller ei tohiks sisaldada SQL-päringuid. Parem on neid mudelites hoida. Kontroller ei tohiks sisaldada HTML-i ega muid märgistusi. Tasub see nähtavale tuua.
Hästi läbimõeldud MVC-rakenduses on kontrollerid tavaliselt väga õhukesed ja sisaldavad vaid paarkümmend rida koodi. Sama ei saa öelda Stupid Fat Controllerite (SFC) kohta CMS Joomlas. Kontrolleri loogika on üsna tüüpiline ja suurem osa sellest kantakse üle baasklassidesse.
Mudelid, vastupidi, on väga paksud ja sisaldavad enamikku andmetöötlusega seotud koodist, kuna selles sisalduv andmestruktuur ja äriloogika on tavaliselt konkreetse rakenduse jaoks üsna spetsiifilised.
Loodan, et olete juba märganud, et erinevatel saitidel võib olla täiuslik erinevad vormingud Ehitus aadressiriba. Iga vorming võib kuvada veebirakenduse arhitektuuri. Kuigi see ei ole alati nii, on see enamikul juhtudel selge tõsiasi.
Vaatleme kahte aadressiriba valikut, mis kuvavad teksti ja kasutajaprofiili.
Ligikaudne töötlemiskood sel juhul:
switch($_GET["action"]) ( suurtäht "about" : nõuda_once("about.php"); // "Teave meist" lehe katkestus; suurtäht "contacts" : request_once("contacts.php"); // "Kontaktid" lehekülje paus "feedback" : request_once("feedback.php") vaikimisi: request_once("page404.php");
Ma arvan, et peaaegu kõik on seda varem teinud.
URL-i marsruutimismootori abil saate konfigureerida oma rakenduse sama teabe kuvamiseks selliseid päringuid vastu võtma:
http://www.example.com/contacts/feedback
Siin tähistavad kontaktid vastutavat töötlejat ja tagasiside on kontaktide kontrolleri meetod, mis kuvab tagasiside vormi jne. Selle teema juurde tuleme tagasi praktilises osas.
Samuti tasub teada, et paljude veebiraamistike ruuterid võimaldavad luua kohandatud URL-i marsruute (täpsustage, mida iga URL-i osa tähendab) ja reegleid nende töötlemiseks.
Nüüd on meil piisavalt teoreetilisi teadmisi, et praktikasse edasi liikuda.
Tulevikku vaadates ütlen, et põhikausta salvestatakse põhiklassid Model, View ja Controller.
Nende lapsed salvestatakse kontrollerite, mudelite ja vaadete kataloogidesse. Fail index.php on rakenduse sisenemispunkt. Fail bootstrap.php algatab rakenduse laadimise, ühendab kõik vajalikud moodulid jne.
Me läheme järjestikku; Avame faili index.php ja täidame selle järgmise koodiga:
ini_set("kuva_vead", 1); request_once "application/bootstrap.php";
Siin ei tohiks olla küsimusi.
Järgmiseks läheme kohe faili bootstrap.php juurde:
nõuda_once "core/modell.php"; request_once "core/view.php"; request_once "core/controller.php"; request_once "core/route.php"; Marsruut::start(); //käivitage ruuter
Esimesed kolm rida sisaldavad praegu olematuid tuumafaile. Viimased readühendage fail ruuteri klassiga ja käivitage see helistades täitmiseks staatiline meetod alustada.
RewriteEngine on RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-d RewriteRule .* index.php [L]
See kood suunab kogu lehe töötlemise ümber saidile index.php, mida me vajame. Mäletate, esimeses osas rääkisime eesmisest kontrollerist?!
Asetame marsruudi sisse eraldi fail route.php põhikataloogi. Selles failis kirjeldame klassi Route, mis käivitab kontrolleri meetodeid, mis omakorda genereerivad lehevaate.
Faili route.php sisu
class Route ( staatiline funktsioon start() ( // kontroller ja vaiketoiming $controller_name = "Main"; $action_name = "index"; $routes = explode("/", $_SERVER["REQUEST_URI"]); // saada kontrolleri nimi if (!empty($routes)) ( $kontrolleri_nimi = $marsruudid; ) // hangi toimingu nimi if (!empty($routes)) ( $tegevuse_nimi = $marsruudid; ) // lisa eesliited $mudeli_nimi = "Model_".$kontrolleri_nimi = "Juhtija_nimi"; $tegevuse_nimi = "tegevuse_nimi" ($mudeli_nimi) ".php"; $model_path = "rakendus/mudelid/".$model_file kontrolleriklassiga $kontrolleri_fail = strtolower ($kontrolleri_nimi).php"; $kontrolleri_tee = "rakendus/kontrollerid/".$kontrolleri_fail; if(faili_exists($kontrolleri_tee)) ( sealhulgas "rakendus/kontrollerid/".$kontrolleri_fail; ) else ( /* siin oleks õige erand visata, aga asja lihtsustamiseks suuname kohe 404 lehele */ Route::ErrorPage404(); ) // loo kontroller $kontroller = new $kontrolleri_nimi ; $tegevus = $tegevuse_nimi; if(method_exists($controller, $action)) ( // kutsub kontrolleri toimingut $controller->$action(); ) else ( // siin oleks ka targem visata erand Route::ErrorPage404(); ) ) function ErrorPage404( ) ( $host = "http://".$_SERVER["HTTP_HOST"]."/"; päis("HTTP/1.1 404 Ei leitud"); header("Olek: 404 ei leitud"); header("Asukoht:".$host."404"); ) )
Märgin, et klass rakendab väga lihtsustatud loogikat (vaatamata mahukale koodile) ja võib esineda isegi turvaprobleeme. Seda tehti tahtlikult, sest... täisväärtusliku marsruutimisklassi kirjutamine väärib vähemalt eraldi artiklit. Vaatame põhipunkte ...
Elemendis globaalne massiiv$_SERVER["REQUEST_URI"] sisaldab täielik aadress millega kasutaja ühendust võttis.
Näiteks: example.ru/contacts/feedback
Funktsiooni kasutamine plahvatada Aadress on jagatud komponentideks. Selle tulemusena saame kontrolleri nime, antud näite puhul on see kontroller kontaktid ja toimingu nimi, meie puhul - tagasisidet.
Järgmisena ühendatakse mudelifail (mudel võib puududa) ja kontrolleri fail (kui see on olemas) ning lõpuks luuakse kontrolleri eksemplar ja toimingut kutsutakse uuesti, kui seda oli kirjeldatud kontrolleri klassis.
Seega, kui minna näiteks aadressile:
example.com/portfell
või
example.com/portfolio/index
Ruuter teeb järgmised toimingud:
example.com/ufo
siis suunatakse ta lehele „404”:
example.com/404
Sama juhtub ka siis, kui kasutaja siseneb toimingule, mida kontrolleris pole kirjeldatud.2.2. Pöördume tagasi MVC juurutamise juurde. Liigume põhikausta ja lisame faili route.php veel kolm faili: model.php, view.php ja controller.php
Lubage mul teile meelde tuletada, et need sisaldavad baasklasse, mida me nüüd kirjutama hakkame.
Faili model.php sisu
klassi mudel (avalik funktsioon get_data() ( ))
Mudeliklass sisaldab ühte tühja andmete toomise meetodit, mis alistatakse järeltulijate klassides. Kui loome järglaste klasse, saab kõik selgemaks.
View.php faili sisu
class View ( //public $template_view; // siin saab määrata vaikimisi üldvaate. function generate($content_view, $template_view, $data = null) ( /* if(is_array($data)) ( // convert array elemendid muutujateks ekstrakt($andmed ) */ include "application/views/".$template_view;
Seda meetodit pole raske ära arvata genereerida mõeldud vaate kujundamiseks. Sellele edastatakse järgmised parameetrid:
konkreetse lehe sisu kuvamiseks.
Meie puhul sisaldab üldine mall päist, menüüd, külgriba ja jalust ning lehtede sisu eraldi vorm. Jällegi, seda tehakse lihtsuse huvides.
Faili controller.php sisu
klassi kontroller ( avalik $mudel; avalik $vaade; funktsioon __construct() ( $this->view = new View(); ) funktsioon action_index() ( ) )
meetod action_index- see on vaikimisi kutsutav toiming, mille järeltulijate klasside juurutamisel alistame.
Eelmisel joonisel on fail template_view.php eraldi esile tõstetud – see on kõikidele lehtedele ühist märgistust sisaldav mall. Lihtsamal juhul võiks see välja näha selline:
Kodu
Et anda saidile esinduslik välimus, loome CSS-i malli ja integreerime selle oma saidile, muutes HTML-i märgistuse struktuuri ja CSS-ühendused ja JavaScripti failid:
Artikli lõpus jaotises "Tulemus" on link GitHubi hoidlale, kus on projekt, milles on astutud samme lihtsa malli integreerimiseks.
klass Controller_Main laiendab kontrollerit ( funktsioon action_index() ( $this->view->generate("main_view.php", "template_view.php"); ) )
Meetodi järgi genereerida Vaade klassi eksemplar, edastatakse üldmalli failide nimed ja vaade koos lehe sisuga.
Lisaks indekstoimingule võib kontroller loomulikult sisaldada muid toiminguid.
Vaatasime üldvaate faili varem üle. Mõelge sisufailile main_view.php:
Tere tulemast!
OLOLOSHA TEAM on veebilehtede arendamise valdkonna esmaklassiliste spetsialistide meeskond, kellel on aastatepikkune kogemus Mehhiko maskide, Indiast ja Tseilonist pärit pronks- ja kivikujude, Ekvatoriaal-Aafrika meistrite viie või kuue sajandi jooksul loodud bareljeefide ja skulptuuride kogumisel. tagasi...
See sisaldab lihtsat märgistust ilma PHP-kõnedeta.
Avalehe kuvamiseks võite kasutada ühte järgmistest aadressidest:
Vaatleme näidet, kasutades vaadet, mis kuvab allolevast mudelist saadud andmeid. 2.3.2. Lehe “Portfell” loomine Meie puhul on “Portfelli” leht ainus leht, mis mudelit kasutab.
Mudel sisaldab tavaliselt andmevalimimise meetodeid, näiteks:
Asetage mudelifail model_portfolio.php mudelite kausta. Siin on selle sisu:
class Model_Portfolio laiendab mudelit ( avalik funktsioon get_data() ( return array(array("Year" => "2012", "Site" => "http://DunkelBeer.ru", "Description" =>" Saksamaa tootja Löwenbraü tume õlu Dunkel, mida toodab Venemaal õlletootja "SUN InBev."), array("Year" => "2012", "Site" => "http://ZopoMobile.ru", "Kirjeldus" " => "Vene keelne kataloog Hiina telefonid Zopo ettevõte, mis põhineb Android OS-il ja nende tarvikutel."), // todo); ) )
Mudeli kontrolleri klass sisaldub failis controller_portfolio.php, siin on selle kood:
klass Controller_Portfolio laiendab kontrollerit ( funktsioon __construct() ( $this->model = new Model_Portfolio(); $this->view = new View(); ) funktsioon action_index() ( $data = $this->model->get_data( ); $this->view->generate("portfolio_view.php", "template_view.php", $data ) )
Muutujale andmeid meetodi tagastatud massiiv kirjutatakse hanki_andmed mida me varem vaatasime.
See muutuja edastatakse seejärel meetodi parameetrina genereerida, mis sisaldab ka: üldmalliga faili nime ja lehe sisuga vaadet sisaldava faili nime.
Lehe sisu sisaldav vaade asub failis portfolio_view.php.
Portfell
| aasta | Projekt | Kirjeldus |
Siin on kõik lihtne, vaates kuvatakse mudelist saadud andmed. 2.3.3. Ülejäänud lehtede loomine Ülejäänud leheküljed luuakse samal viisil. Nende kood on saadaval GitHubi hoidlas, mille link on toodud artikli lõpus, jaotises “Tulemus”.3. Tulemus Siin on see, mis lõpuks juhtus:
Saadud visiitkaardi veebisaidi ekraanipilt
GitHubi link: https://github.com/vitalyswipe/tinymvc/zipball/v0.1
Kuid selles versioonis visandasin järgmised klassid (ja neile vastavad tüübid):
- Controller_Login, milles genereeritakse vaade sisselogimise ja parooli sisestamise vormiga, mille täitmist teostatakse autentimisprotseduur ja selle õnnestumise korral suunatakse kasutaja administraatori paneelile.
- Contorller_Admin koos indeksitoiminguga, mis kontrollib, kas kasutajal oli saidil varem administraatoriks volitused (kui jah, kuvatakse administraatori paneeli vaade) ja väljalogimistoiminguga.
Kuid mitmesajast failist koosnevate veebiraamistike, nagu Yii või Kohana, kasutamine lihtsate veebirakenduste (näiteks visiitkaardisaitide) arendamisel ei ole alati soovitatav. Nüüd saame luua ilusa MVC mudeli, et mitte segada Php, HTML, CSS ja JavaScripti koodühes failis.
See artikkel on pigem CMF-i õppimise lähtepunkt kui näide millestki tõeliselt õigest, mida saate oma veebirakenduse aluseks võtta. Võib-olla inspireeris see teid isegi ja mõtlete juba MVC-l põhineva mikroraamistiku või CMS-i kirjutamisele. Aga enne järgmise ratta leiutamist “blackjacki ja hooradega” mõelge uuesti: ehk oleks mõistlikum suunata oma jõupingutused juba olemasoleva projekti arendamisele ja kogukonna abistamisele?!
P.S.: artikkel kirjutati ümber, võttes arvesse mõningaid kommentaaridesse jäänud kommentaare. Kriitika osutus väga kasulikuks. Otsustades vastuse järgi: kommentaarid, PM-id ja postituse lemmikutesse lisanud kasutajate arv, ei osutus selle postituse kirjutamise idee nii hulluks. Kahjuks ei saa ajapuudusel kõiki soove arvesse võtta ja rohkem ja täpsemalt kirjutada... aga ehk teevad seda need salapärased isikud, kes algversiooni alla hääletasid. Edu teie projektidele!
5. Valik kasulikke linke sellel teemal Artikkel puudutab väga sageli veebiraamistike teemat – see on väga lai teema, sest isegi mikroraamistikud koosnevad paljudest osadest, mis on omavahel nutikalt omavahel ühendatud ja nendest rääkimiseks kuluks rohkem kui üks artikkel. komponendid. Siiski otsustasin siinkohal esitada väikese valiku linke (mida ma seda artiklit kirjutades järgisin), mis ühel või teisel viisil on seotud raamistike teemaga.Sildid: lisa sildid
Tere päevast, kallid kolleegid. Selles artiklis tahaksin rääkida oma analüütilisest arusaamast MVC, MVP ja MVVM mustrite erinevustest. Mind ajendas seda artiklit kirjutama soov mõista kaasaegseid lähenemisviise suure tarkvara arendamiseks ja sellega seonduvalt arhitektuurilised omadused. Oma karjääriredeli praegusel etapil ei ole ma otsene arendaja, seega võib artikkel sisaldada vigu, ebatäpsusi ja arusaamatusi. Kas olete huvitatud sellest, kuidas analüütikud programmeerijate ja arhitektide tegevust näevad? Siis tere tulemast kassi.
Lingid Esimene asi, millest tahaksin alustada, on lingid välismaterjalid, mis juhendas mind selle artikli kirjutamisel:Sissejuhatus Ajal, mil päike paistis eredamalt ja muru oli rohelisem, töötas rühm üliõpilasi, nagu selle artikli autor, tarkvara, kirjutades sadu koodiridu otse toote liidesesse. Mõnikord kasutati andmetega töötamiseks teenuseid ja haldureid ning seejärel saadi lahendus dokumendivaate mustri abil. Sellise koodi toetamine nõudis tohutuid kulutusi, kuna uuele arendajale tuli koolitada (ütleda), milline kood mille eest tootes vastutab ja mingist ühikutestimisest polnud juttugi. Arendusmeeskond koosneb 4 inimesest, kes istuvad ühes ruumis.
Aeg läks, töö muutus. Arendatavad rakendused muutusid ühest tihedast arendajate meeskonnast palju suuremaks ja keerukamaks erinevad meeskonnad arendajad, arhitektid, kasutatavuse spetsialistid, disainerid ja PM-id. Nüüd vastutab igaüks oma valdkonna eest ise: GUI, äriloogika, komponendid. Ilmus analüüsi, testimise ja arhitektuuri osakond. Tarkvaraarenduse kulud on kasvanud sadu ja isegi tuhandeid kordi. Selline arenduskäsitlus eeldab stabiilset arhitektuuri, mis sünkroniseeriks toote erinevad funktsionaalsed valdkonnad. Mustrid Arvestades keeruka tarkvara arendamise tööjõukulude vähendamise eesmärki, eeldame, et on vaja kasutada valmis ühtseid lahendusi. Lõppude lõpuks hõlbustavad mallitoimingud arendajate vahelist suhtlust, võimaldavad viidata tuntud kujundustele ja vähendada vigade arvu.
Wikipedia järgi on disainimuster korratav arhitektuuriline projekt, mis kujutab endast lahendust disainiprobleemile mõnes sageli esinevas kontekstis.
Alustame esimese peamise asjaga – Model-View-Controller. MVC on põhimuster, mis on leidnud tee paljudesse tehnoloogiatesse, tekitanud uusi tehnoloogiaid ja muudab arendajate elu iga päev lihtsamaks.
Esiteks MVC muster ilmus SmallTalki keeles. Arendajad oleksid pidanud selle välja mõtlema arhitektuurne lahendus, mis võimaldaks meil lahku minna GUIäriloogikast ja äriloogikast andmetest. Seega koosneb MVC oma klassikalises versioonis kolmest osast, mis annavad sellele nime. Vaatame neid:
Mudel Mudelit mõistetakse tavaliselt osana, mis sisaldab rakenduse funktsionaalset äriloogikat. Mudel peab olema ülejäänud tootest täiesti sõltumatu. Mudelikiht ei pea teadma midagi kujunduselementide ega selle renderdamise kohta. Saavutatakse tulemus, mis võimaldab teil muuta andmete esitusviisi, nende kuvamisviisi, ilma mudelit ennast puudutamata.Mudelil on järgmised omadused:
- Mudel on rakenduse äriloogika;
- Mudelil on teadmised enda kohta ja ta ei tea kontrolleritest ja vaadetest;
- Mõne projekti puhul on mudel lihtsalt andmekiht (DAO, andmebaas, XML-fail);
- Teiste projektide puhul on mudeliks andmebaasihaldur, objektide komplekt või lihtsalt rakendusloogika;
Esitusel on järgmised omadused:
- Vaade rakendab mudelist saadud andmete kuvamist mis tahes viisil;
- Mõnel juhul võib vaates olla kood, mis rakendab mõnda äriloogikat.
- Model-View-Controller
- Model-View-Esitleja
- Mudel-vaade-vaate mudel
Vaatleme ja võrdleme neid kõiki.
Model-View-EsitlejaSee lähenemine võimaldab luua esituse abstraktsiooni. Selleks peate valima konkreetse atribuutide ja meetodite komplektiga vaateliidese. Saatejuht saab omakorda viite liidese juurutamise kohta, tellib esitlusüritused ja muudab mudelit nõudmisel.
Saatejuhi märgid:
- Vaade suhtleb otse esitlejaga, kutsudes esile vastavaid funktsioone või sündmusi esineja eksemplaril;
- Ettekandja suhtleb vaatega, kasutades spetsiaalset liidest, mille rakendab Vaade;
- Üks esitleja eksemplar on seotud ühe kuvaga.
Rakendamine:
Iga vaade peab rakendama vastava liidese. Vaadeliides määratleb kasutajaga suhtlemiseks vajalike funktsioonide ja sündmuste komplekti (näiteks IView .ShowErrorMessage(string msg)). Ettekandjal peab olema viide vastava liidese realiseerimisele, mis reeglina konstruktoris läbitakse.
Esitlusloogikas peab olema viide esitaja eksemplarile. Kõik vaatesündmused edastatakse töötlemiseks ettekandjale ja esitusloogika ei töötle neid peaaegu kunagi (sh muude vaadete loomine).
Kasutusnäide: Windows Forms.
Mudel-vaade-vaate mudel
See lähenemisviis võimaldab teil seostada vaateelemente vaatemudeli atribuutide ja sündmustega. Võib väita, et selle mustri iga kiht ei tea teise kihi olemasolust.
Vaatemudeli omadused:
- Kahepoolne suhtlus esitlusega;
- Vaatemudel on vaate abstraktsioon. Tavaliselt tähendab see, et vaate omadused on samad, mis vaate/mudeli atribuudid
- Vaatemudelil puudub viide vaateliidesele (IView). Vaatemudeli oleku muutmine muudab vaadet automaatselt ja vastupidi, kuna kasutatakse andmete sidumismehhanismi (Bindings)
- Vaatemudeli üks eksemplar on seotud ühe vaatega.
Rakendamine:
Selle mustri kasutamisel ei rakenda vaade vastavat liidest (IView).
Vaatel peab olema link andmeallikale (DataContex), milleks antud juhul on Vaade mudel. Vaateelemendid on seotud vaatemudeli vastavate atribuutide ja sündmustega.
Vaatemudel omakorda rakendab spetsiaalset liidest, millega on harjunud automaatne värskendus esitluselemendid. Sellise liidese näide WPF-is oleks INotifyPropertyChanged.
Kasutamise näide: WPF
Model-View-Controller
Selle mustri põhiidee on see, et nii kontroller kui ka vaade sõltuvad mudelist, kuid mudel ei sõltu neist kahest komponendist.
Kontrolleri omadused
- Kontroller määrab, millist vaadet hetkel kuvada;
- Vaatesündmused võivad mõjutada ainult kontrollerit. Kontroller võib mõjutada mudelit ja määrata teise vaate.
- Ainult ühe kontrolleri jaoks on võimalik mitu vaadet;
Rakendamine:
Kontroller peatab sündmuse väljastpoolt ja vastavalt sellesse sisseehitatud loogikale reageerib sellele sündmusele, muutes mudelit, kutsudes välja sobiva meetodi. Pärast muudatust kasutab mudel sündmust, mida ta on muudetud, ja kõik selle tellitud View sündmused pöörduvad pärast selle saamist mudeli poole, et saada uuendatud andmeid, misjärel need kuvatakse.
Kasutusnäide: MVC ASP.NET
Kokkuvõte MVVM ja MVP mustrite rakendamine tundub esmapilgul üsna lihtne ja sarnane. MVVM-i puhul toimub aga vaate sidumine View-mudeliga automaatselt, kuid MVP jaoks on vaja programmeeridaNäib, et MVC-l on vaate üle suurem kontroll. Üldreeglid mustrivalik MVVM
- Kasutatakse olukorras, kus andmete sidumine on võimalik, ilma et oleks vaja sisse viia spetsiaalseid vaateliideseid (s.t. puudub vajadus IView juurutamiseks);
- Levinud näide on WPF-tehnoloogia.
- Kasutatakse olukorras, kus andmete sidumine pole võimalik (Sidumist ei saa kasutada);
- Levinud näide oleks Windowsi vormide kasutamine.
- Kasutatakse olukorras, kus suhtlus vaate ja rakenduse muude osade vahel ei ole võimalik (ja te ei saa kasutada MVVM-i ega MVP-d);
- Levinud kasutusjuht on ASP.NET MVC.
Tänan teid väga aja eest, nautige lugemist!
Mis on MVC?Niisiis, MVC puudutab kasutajaliidest (UI). Mitte tingimata graafiline, hääljuhtimine on ka hea. Ärgem unustagem, et programmil ei pruugi olla kasutajaliidest, aga võib olla tarkvara liides(API) või üldse mitte ja olla siiski kasulik.
Aga kui meil on kasutaja, siis peab kasutajaliides olema. Mis on liides? See on külgnev piir kahe süsteemi vahel. Meie puhul: ühelt poolt - programm, teiselt poolt - kasutaja. Siin nad on.
Programm on täiesti abstraktne, mis tahes teemakood. See võib teha midagi kasulikku ja kasutajal on vajadused, mida saab selle programmi abil rahuldada. Siis ilmuvad loogikatükid, mis "teavad", kuidas seda programmi kasutades teha otse seda, mida kasutaja soovib. Palad ei ole ainespetsiifiline, ainespetsiifiline loogika programmis. Need on kasutaja jaoks tema spetsiifiliste vajadustega asjakohasemad ning on kõnede ja kõnede kombinatsioonid programmile.
KasutusjuhtumidKujutage näiteks ette terminali börsil kauplemiseks. Terminali kasutaja esitab avalduse, milles märgib, et soovib osta 20 ettevõtte Svetly Put aktsiat hinnaga 1500 rubla aktsia kohta. Samuti näitab see, et avaldus kehtib neli tundi ja milliselt tema kontolt debiteeritakse raha tehingu õnnestumise korral.
Käegakatsutav hulk atribuute. Möödub mõni aeg ja ta mõistab, et ta ei saa selle hinnaga osta ja on valmis tõstma hinda 1550 rublani, jättes alles kõik muud väärtused. Seejärel valib ta selle rakenduse, klõpsab nuppu "redigeeri", näitab uus hind, Jah. See on mugav.
Kuid börsil ei saa te tellimust muuta. Taotlust saab ainult esitada ja tühistada. Et anda kasutajale võimalus tellimust ühe klõpsuga muuta, tuleb meeles pidada vanad väärtused, eemaldada tellimus, lasta tal muuta seda, mis meelde jäi, ja esitada uus tellimus. Selline kombinatsioon. Kuid kasutaja jaoks näeb see välja ühe lihtsa toiminguna: rakenduse muutmine. Seda nimetatakse kasutusjuhtumiks.
Täiendame oma diagrammi ruumi kasutusjuhtumite jaoks.
Samuti tuleks kasutajale anda võimalus neid kasutusjuhtumeid tõmmata ja tulemusi saada. Need võivad olla nupud ja muud graafilised sisend-/väljundelemendid, žestid, kõnetuvastus ja süntees. Mis tahes võimalus andmete ja käskude vahetamiseks. Voila:
Kasutaja tõmbab ühe kasutusjuhtudest, mis omakorda manipuleerib programmiga. Programm avaldab tulemuse või muudatused selle olekus.
Kus siis ikkagi on MVC?Jääb üle vaid saadud komponentidele tuttavad nimed anda.
Kui mudel avaldab muudatusi, siis pole tal vahet, kelle jaoks, ta ei tea View'st midagi. Vaate asemel või koos sellega võib teises otsas olla mõni muu alamsüsteem.
Nüüd mõned üksikasjad.
See oli klassikaline versioon MVC – aktiivne mudel. Samuti juhtub, et mudel ei teavita muudatustest. Seejärel võtab vastutav töötleja selle vastutuse. Ta teab, milliseid manipulatsioone ta mudeliga teeb, ja ilmselt ta teab, millised muutused mudeli seisundis võivad järgneda. See on passiivne mudel.
Ja üks hetk. Koodi jagamine subjektiks ja mittesubjektiks on tinglik ja sõltub sellest, kui pedantselt me modelleerida tahame ainevaldkond. Mõnikord on ratsionaalne otsus lisada mudelisse mingi kasutusjuht. Võib-olla vähendab see koodi kogust ja lihtsustab seda.
Täname materjali eest meie tellijat Stanislav Iljitševit
Toas
kaitseelement- Vesimärk: traditsioon ja innovatsioon
Kohtumispaik- See on homne raha
vaatepunktist- Esilinastused ja trendid
tead kuidas- Kahe näoga kaitse
tead kuidas- Kogu saladus on objektiivides
dokument - Kanada pass: tehnikakunst
arengut - Turvakiud: uued võimalused
templid- Plaadid, nikkel ja Brodski luuletused
ajaloo märgid- Postkaardid: tee "postitelegrammist" propagandaplakatini
ekskursioon- Armeenia draamad: raha illustreerib ajalugu
Lihtne kontrollida, raske korrata
IN viimased aastad Goznak arendab ja turustab aktiivselt kõige tõhusamaid kaitsetehnoloogiaid. Nende hulgas eristuvad kaks suunda: luua valgusele nähtavaid elemente ning nihke ja metallograafia kombinatsiooni abil saadud funktsioone.
Tänapäeval on pangatähtede tööstuses suurem nõudlus tõhusate tehnoloogiliste ja turvalahenduste järele kui kunagi varem. Viimastel aastatel on Goznak maksnud Erilist tähelepanu selliste lahenduste väljatöötamine ja turule toomine, mille kontseptsiooni saab sõnastada järgmiselt: standardvarustuse abil saadud kergesti tuvastatavate, kuid raskesti reprodutseeritavate turvaelementide väljatöötamine. Sellist lähenemist tõhusate turvatehnoloogiate arendamisele illustreerime kahe suuna arendamise näitel: edastuse kaudu nähtavate optiliselt muutuvate tunnuste saamine ning ofset- ja sügavtrüki kombineerimisel saadud tunnused.
Valgustatud tehnoloogiad
Läbiva valguse käes paberil vaadeldav vesimärk on elanikkonna seas endiselt kõige populaarsem turvaelement. Samas on see tehnoloogiliselt arenenud ning vesimärkidega paberi valmistamise kogemused ulatuvad enam kui seitsme sajandi taha. Sellepärast on viimastel aastatel tänu ühtsete toodete valmistamise uute tehnoloogiate ilmnemisele see kaitsefunktsioon saanud uue arengu. Peaaegu kõigi moderniseeritud pangatähtede mitmetoonilised vesimärgid on astunud mitmevärviliste ja filigraansete märkide kombineerimisel saadud vesimärkidele. Ja praegu rakendatakse aktiivselt vesimärkide saamise tehnoloogiat keeruka mitmetasandilise filigraani abil. Ajakiri Watermark on nendest vesimärkidest korduvalt rääkinud. See tehnoloogia võimaldab saada mitte ainult märgi kontrastsed heledad alad, vaid ka vesimärkidele ebatüüpilised kõrge joonega kujutised.
Turvaniidid, nagu ülekandega juhitavad vesimärgid, pole erinevalt viimastest nii pikk ajalugu- veidi rohkem kui poolteist sajandit. Siiski on nad kindlalt kinni ülemine tase kaitsetehnoloogiad. Selle põhjuseks on nii turvaniitidega paberi hea valmistatavus kui ka nende laialdane võime toimida erinevate turvaelementide ja -efektide kandjana. Vaatamata näiliselt vaieldamatutele eelistele vesimärkidega võrreldes on neid oluliselt rohkem kõrge hind Turvaniidid ise vähendavad nende kasutamise efektiivsust, eriti väikese nimiväärtuse korral, kus reeglina kasutatakse kõige lihtsamaid ja vastavalt ka odavamaid niidivalikuid. Seetõttu oli Goznaki turvaniitide arendamise üheks suunaks suure pindalaga läbipaistva akna valmistamine paberist, võttes paberi valamisel kasutusele laia läbipaistva polümeerteibi, millele järgnes standardsete materjalide kasutamine. trükitehnoloogiad kaitsva efekti saavutamiseks akna piirkonnas. Kuna polümeerkile, millest lint on valmistatud, on masstoodang ja ei sisalda eksklusiivseid kaitseomadusi, on selle maksumus oluliselt madalam kui värvimuutuvate, optiliselt muutuvate ja muude kõrgtehnoloogiliste omadustega niitide maksumus. Samal ajal saab sarnaseid väga turvalisi optiliselt muutuvaid funktsioone saada traditsiooniliste printimistehnoloogiate abil, mis teeb selle tehniline lahendus tõhusam.
Just sellist lähenemist rakendati ka Sotši 2014. aasta mälestuspangatähe puhul. Läbipaistvas aknas, mis saadakse mõõna ajal paberisse laia polümeerlindi sisestamisel, valmistatakse metallograafilisel meetodil optiliselt muutuv kaitseelement “Sebra”. Valguse käes vaadates ja sujuvalt pangatähte pöörates näete, kuidas lumehelbe kujutis aknas muutub negatiivsest positiivseks.
Mis siis, kui te ei kasuta polümeerlinti, et saada optiliselt muutuv funktsioon, mida juhib edastus? Või muul viisil, kuidas saada optilist muutuv element, edastusjuhitav, kasutades traditsioonilist pangatähtede tehnoloogiat? Just see ülesanne oli direktoraadi töötajatele seatud kaitsetehnoloogiad ja Goznaki uurimisinstituudi spetsialistid 2014. aastal. Eesmärk on ilmne: vabaneda "lisaelemendist" - laiast polümeerlindist ja selle paberisse viimise keerulisest tehnoloogiast, s.o. turvalahendus veelgi tõhusam.
Ülesanne osutus väga keeruliseks, kuna ühelt poolt mõjutas lõpptulemust suur hulk tegureid ja teisest küljest osutusid peamised tegurid mitte ainult omavahel tihedalt seotud, vaid ka omavahel vastuolus olnud. Ma pidin vaatama mittestandardsed lahendused. 2014. aasta lõpuks tõestati pärast uurimistööd selliste kaitseelementide saamise põhimõtteline võimalus. 2015. aastal lasi FSUE Goznak välja reklaampangatähe “Vene Avangard”, mille esitles asetäitja peadirektor A. B. Kurjatnikovi teaduse ja arengu kohta ajakirja “Vesimärk” 2015. aasta teises numbris. Reklaampangatähel on turvaelement "Siluett" - optiliselt muutuv element, mis on nähtav läbiva valguse käes ja on valmistatud traditsiooniliste pangatähtede trükkimise tehnoloogiate abil läbipaistvas aknas, mis on saadud traditsioonilise pangatähtede paberi valmistamise tehnoloogiaga. Praegu tehakse tööd poolläbipaistva akna saamise tehnoloogia täiustamiseks ja trükitud elementide disaini optimeerimiseks.
Täringumäng
MVC, MVC+, HMC... Need FSUE Goznakis välja töötatud turvaelementide nimede lühendid on ajakirja lehekülgedel regulaarselt ilmunud alates 2004. aastast. Ja kui kogute kokku kõik sellel teemal kirjutatud artiklid, saate terve loo meie arvates ühe tõhusaima kaitseala sünnist, kujunemisest ja arengust. Selle suuna eripära on see, et turvaelementide reprodutseerimiseks kasutatakse kombinatsiooni geomeetrilistes parameetrites kooskõlastatud joonte kujul, mis on trükitud ofset- ja sügavtrüki meetodil.
Venemaa Panga moderniseeritud pangatähtedesse ilmunud turvaelement MVC Moire Variable Color oli mõeldud eelkõige kopeerimiskaitseks. Tuletagem meelde, kuidas see funktsioon töötab: esialgu homogeensele väljale ilmuvad pangatähte kallutades muarevärvi triibud. See optiliselt muutuv efekt koopial puudub, st värvilised muaaretriibud ei ilmu või tuvastatakse kohe ja pilt jääb muutumatuks, olenemata pangatähtede kallutamisest või pööramisest. Selle omaduse potentsiaal osutus palju suuremaks, kui algselt arvati, tänu oma suurele imitatsioonikindlusele, valmistatavusele, kulumiskindlusele ja võimalusele seda edasi moderniseerida. Selle rakendamise lihtsus 2004. aasta linna moderniseerimisseeria pangatähtedel ja Goznaki spetsialistide poolt sellega seoses oodatud kiired imitatsioonid sundisid seda turvaelementi moderniseerima, et luua muareemuster, mida võltsijatel on raskem reprodutseerida. mittelineaarse joonestruktuuri kasutamisele ning tindivaba reljeeftrükkimise ja värvilise sügavtrüki kombinatsiooni kasutamisele. Nii ilmus optiliselt muutuva funktsiooni MVC+ järgmine põlvkond. Sellel turvaelemendil on kaks kooskõlastatud ala. Alumises piirkonnas on muare muster nähtav mis tahes nurga alt, samas kui ülemises piirkonnas, nagu MVC puhul, ilmub see ainult teatud nurga all. Väga oluline on teada, et pangatähte kallutades peaks ülemise ja alumise osa muaremuster moodustama ühe pideva pildi, ilma et nende kahe ala piiril olevaid muarejooni nihutaks. Lisaks täiustab seda kaitsefunktsiooni sularahakaitse tase. Vaadates MVC+ elementi UV-valguses, saate jälgida täpselt sama muaree efekti nagu päevavalguses. Turvaelementi MVC+ kasutatakse 2010. aastal moderniseeritud 1000- ja 5000-rublastes nimiväärtustes Venemaa Panga pangatähtedes.
Paralleelselt MVC+-ga töötati välja uus kaitseelement, millel on suurem visuaalne efekt. Ja 2010. aastaks loodi uus turvafunktsioon HMC (Hidden Multi Color), millest sai selle funktsioonide seeria veelgi tõhusam turvaelement. Seoses nihke- ja metallograafiliste joonte geomeetriliste parameetrite muutumisega pangatähe kallutamisel jagatakse algselt homogeenne väli eraldiseisvateks eri värvidega värvitud fragmentideks. Numbreid kasutatakse värviliste fragmentidena, tekstimärgid, geomeetrilised kujundid, suvalised alad. Tavaliselt ei kasutata rohkem kui 2-3 värvi. Oluline omadus see kaitsefunktsioon on võimalik lisakontroll selle autentsus. Kui mäletate pangatähte kallutades nähtavaid värve ja pöörate seejärel rahatähte oma tasapinnas 180 kraadi, näete fragmentide täiesti erinevaid värve. See efekt saavutatakse tänu joonte erilisele kujule ja ainulaadsete seadmete kasutamisele metallograafiliste vormide valmistamiseks. Sarnaselt MVC+ elemendile on ka HMC turvaelemendil täiendav rahaline autentimistase: UV-valgusega kokku puutudes näete täpselt samu optiliselt muutuvaid efekte nagu päevavalguses. HMC turvaelement viidi 2010. aasta modifikatsiooni Venemaa Panga 500-rublase pangatähe turvakompleksi.
MVC - HMC seeria kaitseelementide saamiseks kasutatakse piisavalt suure reljeefi sügavusega metallograafilisi jooni. Sügavtrükkimisel väga kõrge rõhu tingimustes paber deformeerub, võttes sügavtrüki joonte profiili kuju. Saadud reljeef ilmub nii prinditud lehe esi- kui ka tagaküljele. Kui esikülje reljeef “töötab” MVC – HMC seeria turvaelementides, siis tagumise külje reljeef oli kasutusel alles hiljuti. Goznaki spetsialistid soovitasid huvitav lahendus– optiliselt muutuvate elementide loomine nii pangatähe esi- kui tagaküljele sügavtrükkimisel ainult esiküljele. Selline element töötati välja ja rakendati reklaampangatähel “195 aastat Goznakit”. Täpsem kirjeldus see element nimega CHMC (Combined HMC) on toodud 2013. aasta ajakirjas “Watermark” nr 3. Lisaks sellele, et pangatähe mõlemal küljel on optiliselt muutuvad tunnused, kasutades selleks olulist tehnoloogilised omadused ofsettrükimasin - esi- ja tagakülje trükkimise täpse registreerimise tagamine on saadud esi- ja tagakülje joondamise kontrollimiseks. Seega on CHMC “kolm ühes”, st optilised funktsioonid pangatähe mõlemal küljel ning element, mis kontrollib esi- ja tagakülje joondamist. Selle elemendi oluline omadus on see, et nii MVC kui ka HMC või mõlema kombinatsiooni saab hankida eraldi pangatähe esi- ja tagaküljel. Seega on reklaampangatähel “Russian Avangard” esiküljel kasutatud HMC elementi ning tagaküljel MVC ja HMC kombinatsiooni.
Parima visuaalse efekti saavutamiseks MVC - HMC seeria funktsioonide, eriti HMC loomisel, on vaja nihkejoonte printimisel kasutada eredaid kontrastseid värve. Ideaalne on kasutada CMY värve. Tihti aga ei luba klient rahatähtede moderniseerimisel värve vahetada ega kasutada nii erksaid värve ofsettrükk. Seetõttu tuleb disaini ja visuaalse efekti vahel teha kompromiss. See kehtib eriti HMC elemendi kohta. Just selliste värvi poolest “keerukate” pangatähtede jaoks töötati välja kahe- ja isegi ühevärvilised optiliselt muutuvad HMC-elemendid. Sel juhul on ühevärviline element formaalselt kahevärviline, kuna teise värvina kasutatakse tühikut, st paberi värvi. Seetõttu ei muutu pangatähe kallutamisel selle värv positiivne ega negatiivne pilt.
Lisaks saab MVC - HMC seeria mis tahes elemente täiendada peidetud või varjatud pildiga.
Seega on tänaseks loodud rida efektiivseid optiliselt muutuvaid kaitseelemente, mis on toodetud ofset- ja sügavtrüki kombinatsioonil. See on omamoodi kuubikute komplekt, mille abil saab ehitada erinevatele rahatähtedele ainulaadse turvakompleksi.
MVC - HMC seeria optiliselt muutuvate kaitseelementide väljatöötamine jätkub. On uusi ideid. Ja on täiesti võimalik, et uuel reklaampangatähel või mistahes käibetootes ilmub peagi uus ofset- ja sügavtrüki kombinatsioonil põhinev turvaelemendi teostus.
MVC põhimõte veebiprogrammeerimises (mudel - vaade - kontroller, mudel - vaade (vaade) - kontroller) on üks kõige populaarsemaid. häid ideid kuupäevani. MVC põhimõte on esmapilgul intuitiivne, kuid mitte väga lihtne, kui sellesse süveneda. Kõigepealt vaatame, milleks see mõeldud on.
MVC põhimõte võimaldab teil eraldada rakendusloogika rakendamise, välimus(graafiline liides, GUI) ja kasutaja interaktsioon.
Selle tulemuseks on struktureeritum kood, see võimaldab rohkem spetsialiseerunud inimestel projekti kallal töötada, muudab koodi hooldamise lihtsamaks ning muudab selle loogilisemaks ja arusaadavamaks. Ühe komponendi muutus mõjutab teisi minimaalselt. Võimalik ühendada ühe mudeliga erinevad tüübid, erinevad kontrollerid.
Teisalt eeldab see täitesmasinate suuremat jõudlust, kuid viimasel ajal pole see suureks probleemiks olnud – üha keerulisemaks muutuvad programmeerimislahendused nõuavad tuge ning tugikulud ületavad tunduvalt võimsamate kaasaegsete seadmete kulusid.
MVC põhimõtet kasutavad peaaegu kõik kaasaegsed raamistikud.
Vaatame komponente lähemalt.
Mudel- sisaldab nn "äriloogika" - andmete töötlemine ja kontrollimine, juurdepääs andmebaasidele, esindab sisemine korraldus süsteemid. Mudel ei tohiks kasutajaga otseselt suhelda.
Vaade kirjeldab rakenduse välimust.
Kontroller- ühenduslüli mudeli ja vaate vahel, võtab kasutajalt vastu andmed, edastab need mudelile, võtab vastu töödeldud tulemuse ja edastab selle vaatesse.
Seost saab näha diagrammil:
Pildi allikas: http://www.wikipedia.org Nõuded komponentidele:
Mudelid:
- peab sisaldama atribuute, mis esindavad konkreetseid andmeid;
- peab sisaldama äriloogikat (näiteks valideerimisreegleid), et tagada andmete vastavus nõuetele;
- võib sisaldada koodi andmetega töötamiseks.
- peaks sisaldama peamiselt märgistusi, nagu HTML ja lihtne PHP kood, mida kasutatakse andmete läbimiseks, vormindamiseks ja kuvamiseks;
- ei tohiks otse andmebaasile juurde pääseda. Seda peaksid mudelid tegema;
- ei tohiks otse juurde pääseda $_GET , $_POST ja muudele muutujatele, mis on saadud kasutaja päringust. Seda ülesannet peab täitma kontroller. Vaateid tuleks kasutada ainult kontrollerilt ja mudelilt saadud andmete vormindamiseks;
- pääseb otse juurde kontrolleri või mudelite omadustele ja meetoditele. Seda tuleks siiski teha ainult andmete kuvamise eesmärgil.
- pääseb juurde $_GET , $_POST ja teistele PHP muutujad, mis on saadud kasutaja taotlusest;
- saab luua ja hallata mudeli eksemplare. Näiteks tüüpilise mudeli värskendamise toimingu puhul võib kontroller esmalt luua mudeli eksemplari, seejärel täita selle andmetega kaustast $_POST ja kui mudel on edukalt salvestatud, suunata kasutaja brauseri ümber loodud mudeli lehele. Tasub tähele panna, et mudeli enda salvestamine tuleks realiseerida mudeliklassis, mitte kontrolleris;
- ei tohi sisaldada SQL päringuid. Parem on hoida neid mudelites;
- ei tohi sisaldada HTML-i ega muid märgistusi. Tasub see esitlusse panna.
Lisaks MVC kontseptsioonile on ka palju teisi, näiteks MOVE (mudelid, O operatsioonid, vaated ja E vents) – umbes nagu MVC evolutsioon (võetud siit: http://habrahabr.ru/post/ 147038/), kuid need mõisted on vähem levinud.
