Welkom terug na ons Zend Framework van Scratch reeks! In ons laaste tutoriaal het ons 'n paar basiese dinge oor Zend Framework geleer, soos:
As jou nog nie het nie, moet jou die vorige handleiding lees. Dit sal dit vir jou makliker maak om 'n paar Zend Framework-basiese beginsels te verstaan ​​en jou te help om sommige dinge wat ons in hierdie tutoriaal bespreek, te verstaan.
Die kluis is die Databasis - dit is waar al die belangrikste goedjies gestoor word, en is mooi beskerm teen die buitewêreld.
Die bankiers (Modelle) is al 'n rukkie by die werk, daarom maak hulle al die belangrike besluite. Dit bring ons by 'n ander reël: *Hou soveel besigheidslogika in die Model as moontlik*. Die beheerders, ons gemiddelde werkers, moet sulke besluite nie neem nie, hulle vra die bankier vir besonderhede, kry die inligting en stuur dit aan die kliënt (die View). Daarom gaan ons voort om die reël van *vet Modelle, skinny beheerders* te volg. Die gophers maak nie belangrike besluite nie, maar hulle kan nie dom wees nie (dus 'n bietjie besigheids logika in die kontroleerder is OK). Maar sodra die gopher te veel begin dink, word die bankier ontsteld en word jou bank (of jou app) uit die sak. So onthou altyd om soveel besigheidslogika (of besluitneming) aan die model af te laai.
Nou, die bankiers is seker, soos die hel, gaan nie direk met die kliënte (die View) praat nie, hulle is te belangrik in hul sagte stoele hiervoor. So 'n ander reël word gevolg: *Modelle moet nie met Views* praat nie. Hierdie kommunikasie tussen die bankier en die kliënt (die model en die aansig) word altyd deur die gopher (die kontroleur) hanteer. (Ja, daar is 'n mate van uitsondering op hierdie reël vir super VIP-kliënte, maar laat ons basies vir basiese beginsels bly).
So hoe gaan dit met ons kliënt (die View)? Wel, banke maak foute en die kliënt moet slim wees om hul eie rekening te balanseer en besluite te neem. In MVC terme kry ons 'n ander eenvoudige reël: *Dit is redelik goed dat die sienings 'n paar logika bevat, wat handel oor die aansig of aanbieding*. Na aanleiding van ons analogie, sal die kliënt seker maak nie vergeet broek te dra terwyl hulle na die bank gaan nie, maar hulle gaan nie die bankiers vertel hoe om die transaksies te verwerk nie.
Dit is baie skaars dat 'n model direk met 'n Vertoning reageer, maar soms kan dit gebeur wanneer dit nodig is
Hierdie verhoudings maak dit makliker en vinniger vir 'n Kontroleur om inligting te kry, aangesien dit nie met verskillende modelle hoef te reageer nie - die Modelle kan dit self doen
Ons kan sien hoe belangrik Modelle in enige aansoek is, aangesien dit repsonsible is vir enige dinamiese aksies wat in 'n aansoek gebeur. Noudat ons 'n redelike duidelike begrip van die verantwoordelikhede van die Model, sowel as die View and Controller het, kan ons die Modelle in ons aansoek implementeer.
Voordat ons jou eerste Model vir die program skep, benodig ons 'n databasis wat die Model eerste sal verteenwoordig. Kom ons begin met iets eenvoudig - 'n gebruikers tabel, waar ons al die geregistreerde gebruikers vir TheNextSocial sal stoor.
Teken in op jou MySQL databasis en skep 'n databasis genaamd thenextsocial. Sodra jou geskep het, voer die volgende navraag uit om 'n gebruikers tabel te skep, en 'n meegaande gebruikers instellings tabel:
Soos met baie toepassings, is die gebruiklike maakmodelle in Zend Framework die gebruik van 'n gewilde ontwerppatroon wat die "DAO" patroon genoem word. In hierdie patroon het ons die volgende komponente:
Data Objek (Data) wat 'n ry uit ons databasis verteenwoordig, nadat die DataMapper die data daarheen gekaart het
Kom ons begin met die skep van 'n Table Data Gateway vir die gebruikers tabel met behulp van die zf CLI tool:
Maak die User.php lêer oop wat in die program / modelle /DbTable lêer gevind word en dit moet so lyk:
Die lêer UserMapper.php sal nou leeg wees, maar ons sal later 'n kode inbring. Vir nou moet ons die Data Objek skep, wat die Gebruikers model is:
__construct() - konstruktor vir die klas. Sodra dit geopenbaar is, skep dit 'n voorbeeld van die Table Data Gateway en stoor dit
getUserById($id) - neem 'n heelgetal $id in wat 'n enkele ry uit die databasis tabel voorstel, haal dit, terug en gee dan 'n Application_Model_User terug met die gegewe data
__set ($ naam, $ waarde) - 'n magiese funksie wat sorg dat al die eienskappe vir die model gestel word.
Kom ons probeer dit uit! As jou die vorige handleiding gevolg het, moet jou 'n IndexController.php lêer hê. Maak dit oop en sit hierdie kode in wat 'n nuwe gebruiker skep:
Basies, die Leer ORM biblioteek trek die meeste uit, of nie al die Model implementering vir 'n toepassing nie. Van die ongelooflike voordele wat ek ontdek het toe ek die Doctrine with Zend Framework gebruik het, is:
Sodra dit afgelaai is, maak dit oop en trek die inhoud uit. Binne, moet jou Doctrine-1.2.4 gids en 'n package.xml lêer sien. Gaan in die gids en jou moet 'n Doctrine lêer, 'n doktrine.php lêer en 'n LICENSE lêer sien.
Kopieer die Doctrine gids en die Doctrine.php lêer en plaas dit binne die sluitpad van jou PHP-installasie. As jou onthou hoe ons die Zend Framework uit die laaste handleiding opstel, is dit waarskynlik dieselfde gids wat jou die lêers van die Zend biblioteek geplaas het.
Binne die Bootstra.php lêer, voeg die volgende kode by om die Doctrine met die aansoek te initialiseer:
Die opstelling wat ek hier gedoen het, is gebaseer op 'n skrif wat ek in die verlede gevind het op http://dev.juokaz.com, wat deur Juozas Kaziukenas, een van die spanlede by die Doctrine projek onderhou word. Ongelukkig is die blog reeds gesluit, dus ek sal nie meer daaraan kan koppel nie. Let ook daarop dat ons 'n ander metode genoem _initAutoload() het. Dit begin basies die Send Autoloader, wat alle gegenereerde modelle in die modelle gyds sal outoloë. Dit spaar ons die moeite om hierdie lêers een vir een in te sluit.
Vervolgens, moet ons die leerstuk CLI script opstel wat ons sal gebruik om modelle uit die databasis te genereer. Gaan terug na die thenextsocial folder en maak 'n gids genaamd scripts. Binne, maak 'n lêer genaamd leer cli.php en plaas die volgende binne:
Gaan terug na jou modelle gids en verwyder die Gebruikers model lêers wat ons daar het. As jou wil, kan u dit eers na 'n ander plek skuif, maar dit moet nie in die gids wees nie. Open dan jou opdrag prompt (of terminale), cd na die scripts gids en tik die volgende opdrag in:
As jou dit gedoen het, kyk weer na jou modelle lêergids en jou moet 'n paar splinternuwe Gebruikers en GebruikersInstellings modelle sien wat deur Doctrine gegenereer is!
As jou die lêers oopmaak, sal jou nie veel binne sien nie. Die meeste van die kode vir die modelle word opgevang deur die doktrinebiblioteek. Deur die Doctrine_Record klas uit te brei, het ons 'n hele paar voorbeboude metodes van die biblioteek beskikbaar. Maak IndexController.php weer oop en vervang die ou toetskode met die volgende:
Kom ons probeer nou meer ingewikkelde dinge - die opgradering van 'n bestaande Gebruiker via voorafgeboude leerstellingsmetodes en die opdatering daarvan. Dateer die kode op sodat dit so lyk:
Noudat jou weet hoe om die Modelle in 'n Zend Framework-aangedrewe program te implementeer, het jou die kennis om dinamiese webwerwe te skep. Probeer om met die program rond te speel, maak 'n paar nuwe beheerders en modelle wat lees, werk, stoor en uitvee uit die databasis.