Este bine să folosiți instrumente bune, dar trebuie să fiți sigur că le folosiți în mod corespunzător și nu doar codificați "funcționează, bine, bine". Din acest motiv, am decis să scriu o listă de lucruri pe care îmi amintesc întotdeauna atunci când iau proiectul cuiva să susțin sau să se consulte cum să înceapă.
Această afirmație este cea mai evidentă, totuși, credeți-mă, am găsit erori în fiecare proiect în care am participat (mai mult de 10 cu Zend Framework în ultimele șase luni).
Dacă este un controler, nu ar trebui să aibă logică de afaceri, dacă este un model, nu trebuie să proceseze parametrii POST etc.
Logica ar trebui să fie în locul ei și ar trebui să fie separată de forme, bootstrapuri, vederi, asistenți etc.
Transferați toate logica de la controler la model sau serviciu. Utilizați formularul numai pentru verificarea și filtrarea datelor, nu procesați datele în formulare.
Ascundeți sesiunile și identificarea utilizatorilor, efectuați toate operațiunile necesare într-un singur loc și furnizați funcții API pentru utilizare în alte părți ale proiectului.
Pot continua și continua, dar sper că ideea devine clară. În cele din urmă, vă veți da seama că este ceva în neregulă când începeți să testați codul: când trebuie doar să testați formularul, trebuie să configurați frontController. cerere, cookie și server de mail.
Din nou, vreau să menționez ușurința testării, pentru că acesta este un lucru pe care trebuie să-l amintiți în mod constant atunci când dezvoltați un program. Testul nu trebuie să modifice variabilele globale. Pentru a obține valoarea, testul ar trebui să utilizeze metodele obiectelor care returnează valorile necesare (de exemplu, IP). Zend Framework oferă clase foarte convenabile pentru accesul la toate variabilele globale, este păcat să nu le folosiți.
Utilizați valorile formularului, nu interogarea
Această recomandare este foarte ușor de urmărit.
Uită-te la următorul exemplu de cod:
După ce formularul este verificat (și, prin urmare, valorile sunt filtrate), datele brute ale interogării $ this -> _ request-> getPost () sunt încă utilizate. Pur și simplu pierdeți multe funcții Zend_Form interesante. de exemplu, elemente ignorate (butoane "trimite"). Mai mult, formularul nu folosește filtre și tu faci filtre, nu-i așa? În plus, pot transfera orice în model, iar modelul însuși trebuie să efectueze validarea datelor. Astfel, în metoda $ form-> getValues (), trebuie să fie implementată nu numai funcționalitatea controalelor, ci și filtrele.
În acest exemplu, metoda de formare a populației () este suprautilizată. Această metodă este concepută pentru a seta valorile inițiale ale formularului. În cazul unei erori, metoda isValid () va seta valorile cerute, deci nu este nevoie de o funcție suplimentară pentru setarea valorilor.
Primul lucru pe care îl fac este să șterg toate apelurile pentru a ieși () și să le refacem folosind excepții sau declarația de returnare. Există foarte puține cazuri când utilizarea uneia dintre aceste funcții poate fi considerată justificată. De exemplu, să examinăm următorul cod pentru controler:
Prima problemă este să credeți că $ this -> _ redirect () va apela ieșirea () și astfel executarea acțiunii va fi finalizată. Deși acest lucru este adevărat, ar trebui să evitați astfel de cazuri. Astfel de apeluri fac imposibilă generarea de evenimente post. În plus, acest lucru face imposibilă sau incorectă testarea. Zend_Test dezactivează apelul de ieșire () în ajutorul ajutătorului, astfel încât în timpul testării nu puteți testa verificarea drepturilor. Pentru a repara acest lucru, trebuie doar să adăugați o întoarcere înainte de a efectua redirecționarea (reveniți $ this -> _ redirect ('/')) și totul va fi bine.
Mai mult, a doua ieșire () este absolut inutilă și face ca codul să nu poată fi folosit pentru testare. Pentru a remedia situația, este suficient să adăugați o întoarcere, nu va lăsa executarea codului ulterior, vizualizarea nu va fi redesenată, deoarece Asistentul ViewRenderer controlează toate redirecționările și, dacă găsește unul, nu face nimic. Pe baza experienței mele, după salvarea datelor din formular, este suficient să se pună doar redirecționarea în cod, desigur fără ieșire ().
Utilizați cadrul în loc de PHP
Acest lucru poate părea puțin ciudat la început, dar dacă utilizați cadrul (în acest caz Zend Framework), nu începeți trucuri și metode de la o aplicație PHP acum cinci ani. De exemplu, aici (acțiunea controlerului):
Nici nu știu de unde să încep. Toată această logică este deja introdusă în obiectul de răspuns, adică Puteți face următoarele:
Aceste două fragmente pot părea identice, dar nu este. Puteți vedea acest lucru foarte ușor, codul nu funcționează cu variabilele globale (header () este o funcție a unei variabile globale) și prelucrarea cererii nu este întreruptă. Controlerul nu emite nici un fel de date (de aceea ecoul nu este folosit), el primește pur și simplu obiectul de cerere și trimite obiectul de răspuns, și asta e tot. Ieșirea datelor de către controler în același mod întrerupe executarea procesului, precum și apelul pentru ieșire (). așa că nu uitați să vă asigurați că nu ați întrerupt acest thread.
Și mai multe adăugări mici
Application.ini descrie proprietatea includePaths. care este folosit pentru a adăuga căi suplimentare la variabila căii. Deși acest lucru funcționează excelent, recomand să nu folosiți această caracteristică, deoarece aceste căi sunt adăugate de fiecare dată când creați o nouă instanță a aplicației (acest lucru este valabil în 1.9, dar se poate modifica și în viitor). Dacă testați controlorii, atunci sigur, de fiecare dată înainte de a începe, creați o nouă instanță. După ce ați efectuat o sută sau două teste, veți observa că viteza timpilor de răspuns este mai mică și mai mică.
Mi-a trebuit câteva ore să găsesc și să rezolv greșeala, încă îmi amintesc toate astea.
Aceasta este doar o mică parte a problemelor și problemelor pe care le-am întâlnit în practica mea, am mai multe de spus. Sper că veți împărtăși, de asemenea, secretele voastre. Vreau să cred că ți-am oferit câteva idei utile despre cum să lucrezi cu Cadrul Zend, iar codul tău va deveni mai frumos, iar timpul de dezvoltare va fi scurtat, deoarece totul va fi transparent și bine organizat.
Dacă informațiile v-au fost utile, puteți să susțineți site-ul.
Trimiteți-le prietenilor: