Zend-keret tippek és trükkök, orosz nyelvű zend keretrendszer
Jó eszköz a jó eszközök használatához, de biztosnak kell lennie abban, hogy megfelelően használja őket, és nem csak a kódot "jól működik, oké". Ezért úgy döntöttem, hogy olyan dolgokat jegyezek fel, amelyeket mindig szem előtt tartok, amikor valakinek a projektjét támogatom vagy konzultáltam a kezdéssel.
Ez a kijelentés a legnyilvánvalóbb, azonban hidd el nekem, minden olyan projektben hibát találtam, amelyekbe részt vettem (az elmúlt hat hónapban több mint 10-et a Zend Framework).
Ha ez vezérlő, akkor nincs üzleti logika, ha modell, akkor nem kell a POST paramétereket feldolgozni stb.
A logikának a helyén kell lennie, és el kell különülnie az űrlapoktól, a bootstraps-októl, a nézetektől, az asszisztensektől stb.
Átküld minden logikát a vezérlőről a modellre vagy a szolgáltatásra. Az űrlapot csak az adatok ellenőrzéséhez és szűréséhez használja, ne dolgozza fel az adatokat formában.
A munkamenetek és a felhasználói azonosítók elrejtése, az összes szükséges művelet végrehajtása egy helyen, valamint API-funkciók biztosítása a projekt más részein.
Folytathatom és folytathatom, de remélem, hogy az ötlet világossá válik. Végül észre fogod venni, hogy valami hibás, amikor elkezdi tesztelni a kódot: amikor csak meg kell tesztelnie az űrlapot, be kell állítania az frontControllert. kérés, cookie és mail szerver.
Ismét meg szeretném említeni a tesztelés egyszerűségét, mert ez egy olyan dolog, amit folyamatosan emlékezned kell egy program kidolgozásakor. A tesztnek nem szabad módosítania a globális változókat. Az érték megszerzéséhez a tesztnek olyan objektummechanizmusokat kell használnia, amelyek visszaadják a szükséges értékeket (például IP). A Zend Framework nagyon kényelmes osztályokat biztosít az összes globális változó eléréséhez, ezért bűn nem használhatja őket.
Használja az űrlap értékeket, nem pedig a lekérdezést
Ezt az ajánlást nagyon könnyű követni.
Nézze meg a következő kódot:
Az űrlap ellenőrzése után (és ezért az értékek kiszűrésre kerülnek) a $ this -> _ request-> getPost () lekérdezés nyersadatai továbbra is használatban vannak. Ön egyszerűen elveszíti számos érdekes Zend_Form funkciót. például az elemek figyelmen kívül hagyása ("submit" gombok). Ezenkívül az űrlap nem használ szűrőket, és szűrőket állít be, ugye? Továbbá bármit át tudok küldeni a modellnek, és magának a modellnek is végre kell hajtania az adatok hitelesítését. Tehát a $ form-> getValues () metódusban nemcsak az ellenőrzések funkcionalitását, hanem a szűrőket is végre kell hajtani.
Ebben a példában a populate () formátumú metódus túlcsordul. Ezt a módszert úgy tervezték, hogy beállítsa az alap formátumértékeket. Hiba esetén az isValid () módszer megadja a szükséges értékeket, így nincs szükség további funkcióra az értékek beállításához.
Az első dolog, hogy töröljék az összes kilépési () hívást, és kivételektől vagy a visszatérési utasításból átdolgozzák őket. Nagyon kevés olyan eset van, amikor az egyik ilyen funkció használata indokoltnak tekinthető. Például nézzük meg a vezérlő következő kódját:
Az első probléma az a gondolat, hogy $ this -> _ redirect () hívja a kilépést (), és így a művelet végrehajtása befejeződik. Bár ez valóban így van, kerülni kell az ilyen eseteket. Az ilyen hívások lehetetlenné teszik a post * események létrehozását. Ráadásul a tesztelés lehetetlenné vagy helytelenné válik. A Zend_Test letiltja a kilépési () hívást a vezérlő segítői között, így a tesztelés során nem tudja ellenőrizni a jogellenőrzést. A probléma megoldásához, csak adja hozzá a visszatérést az átirányítás végrehajtása előtt (return $ this -> _ redirect ('/')), és minden rendben lesz.
Ezenkívül a második kimenet () teljesen haszontalan, és a kód nem használható a teszteléshez. A helyzet javításához elegendő egy visszatérést adni, nem hagyja, hogy a későbbi kód végrehajtódjon, a nézet nem kerül átsorolásra, mert A viewRenderer segítő vezérli az összes átirányítást, és ha megtalálja, nem tesz semmit. Tapasztalatom alapján az űrlapadatok mentése után elegendő csupán a kód átirányítását, természetesen kilépés nélkül ().
Használja a keretrendszert a PHP helyett
Ez először kissé furcsának tűnhet, de ha a keretet használja (ebben az esetben a Zend Framework), akkor ne kezdjen trükköket és módszereket egy PHP alkalmazásból öt évvel ezelőtt. Például itt (vezérlői tevékenység):
Még azt sem tudom, hol kezdjem. Mindez a logika már beillesztésre került a válaszobjektumba, azaz. A következőket teheti:
Ez a két rész azonosnak tűnhet, de ez nem így van. Ezt jól látod, a kód nem működik globális változókkal (a fejléc () egy globális változó függvénye), és a kérés feldolgozása nem szakad meg. A vezérlő nem ad ki semmilyen adatot (ezért a visszhangot nem használják), egyszerűen megkapja a kérés objektumot, és elküldi a válasz objektumot, és ez minden. A vezérlő által az adatok kimenete ugyanúgy megszakítja a folyamat végrehajtását, valamint a kilépési () hívást. ezért ne felejtsd el meggyőződni róla, hogy nem szakította félbe ezt a szálat.
És még apróbb kiegészítések
Az Application.ini leírja az includePaths tulajdonságot. amely további útvonalakat ad hozzá az elérési útvonal változójához. Bár ez remekül működik, javaslom, hogy ne használja ezt a funkciót, mert ezek az utak hozzáadásra kerülnek az alkalmazás új példányának létrehozásakor (ez 1.9-ben, de a jövőben változhat). Ha teszteli a vezérlőket, akkor biztosan minden alkalommal, mielőtt elkezdi, hozzon létre egy új példányt. Miután elvégeztett száz vagy két tesztet, meglátod, hogy a válaszidők sebessége alacsonyabb és alacsonyabb.
Több órába telt, hogy megtalálja és kijavítsa a hibát, még mindig emlékszem erre.
Ez csak egy kis része azoknak a problémáknak és problémáknak, amelyekkel találkoztam a gyakorlatomban, többet mondok. Remélem, meg fogod osztani a titkaidat is. Azt akarom hinni, hogy hasznos ötleteket adtam neked, hogy hogyan működhet együtt a Zend keretrendszerrel, és a kódod még szebb lesz, és a fejlesztési idő lerövidül, mivel minden átlátható és jól szervezett lesz.
Ha az információ hasznos az Ön számára, támogathatja az oldalt.