Bună ziua tuturor, numele meu este Andrey și eu sunt un simfonist. Am demarat recent un mic proiect de dezvoltare suplimentară a sistemului SAP existent. Înainte de începerea dezvoltării, mi sa oferit să aleg un set de instrumente necesare și am decis să privesc altceva decât Simfonia familiară și familiară.
Nu se poate spune că Symfony nu a fost potrivit pentru rezolvarea problemelor de proiect, dar am fost confundat de cantitatea de cod pe care a trebuit să o scriu pentru ao face "simfonic". Așa că am decis să mă uit la instrumente mai simple.
Alegerea mea a căzut pe Laravel. Judecând după recenzii de pe Internet, este destul de ușor de învățat, are o comunitate mare și se arată bine în implementarea unor proiecte mici și simple. Ce-i în neregulă cu mine, am fost fascinat de utilizarea componentelor symfony în cadrul și am vrut mult timp să văd cât de eficient sunt folosite în alte proiecte.
Laravel împlinise pe deplin așteptările mele:
- Destul de ușor și rapid instalat
- Simplu și ușor de dezvoltat
- Puteți începe imediat să scrieți codul industriei
Pe baza primei mele impresii, am pregătit o scurtă trecere în revistă a cadrului, a arhitecturii și a componentelor sale.
Cadrul este un schelet al structurii proiectului, care oferă funcționalitatea implementată din cutie. Această funcție vă permite să rezolvați cele mai tipice sarcini în dezvoltare. Arhitectura cadrului poate să implementeze un anumit set de modele și să reprezinte implementarea unor modele bine cunoscute.
Arhitectura Laravel este construită în jurul principiului popular recent al Invertorului Control >> Dependent Injection >> Service Container. Acest principiu este familiar dezvoltatorilor Symfony. este piatra de temelie a întregii dezvoltări a Symfoniei.
Container de service Laravel este foarte asemănător cu Symfony cu diferențe minore. Acest lucru nu este surprinzător, deoarece el implementează același model, deși puțin diferit. În general, trebuie remarcat faptul că Containerul de servicii este lipsit de atenție în documentația Laravel. Probabil, dezvoltatorii cadrului nu consideră această componentă centrală în construcția sa. Deși, poate, descrierea detaliată este omisă, pentru a nu complica documentația și pentru a oferi dezvoltatorului posibilitatea de a naviga în lucrul cu componenta în situație.
Mai multe detalii despre principiul inversării controlului și modelele de implementare a acestuia (DependencyInjection >> Service Container și (anti) pattern ServiceLocator) pot fi vizualizate aici:
Laravel folosește o parte din componentele Symfony. Acest lucru nu înseamnă că componentele sunt implementate prin "copy-paste" și, prin urmare, lucrează pe principiul "este suficient să citiți documentația originală și să puteți folosi". Mai degrabă, componentele sunt țesute cu succes în structura cadrului, undeva ușor modificate (înfășurate), undeva completate și ajustate pentru a se încadra în cadrul "ecosistemului". De fapt, acest lucru este destul de logic, pentru că multe componente ale Sf sunt livrate ca un cod gata de utilizare și rezolvă bine sarcinile care sunt puse în fața cadrelor la un nivel general.
Componentele cadrelor: comparați Laravel și Symfony
Din moment ce sunt un simfonist și mă uit la tot cu ochii unui simfonist, voi încerca să compar soluțiile din cadrul Laravel și Symfony.
Principiile HTTP Modul MVC (Controlere, Routing, Vizualizări)
Deci, haideți să ne întoarcem la rădăcinile dezvoltării web, în special, la protocolul HTTP. Oricare ar fi codul dvs. de server, eventual ar trebui să primească un fel de cerere, să o proceseze și să returneze un răspuns specific. Dacă utilizați PHP simplu, puteți obține cu ușurință confuz, de exemplu, cu corpul răspunsului și returnarea anteturilor de răspuns. Dacă ați fost mult timp în dezvoltare, atunci merită să menționați "Anteturi deja trimise" și veți înțelege imediat totul.
Pentru a evita problemele de acest fel, puteți emula lucrarea cu interogarea și răspunsul ca lucrând cu o pereche de clase relevante (obiecte). Componenta HTTPFoundation symfony servește acestui scop. De asemenea, este folosit în Laravel și vă permite să emulați lucrarea la nivelul protocolului HTTP. Simplu și ușor de utilizat. Pentru exemple de folosire a bun venit în documentație.
Modelul MVS este bine cunoscut tuturor, deci este suficient să spunem că este implementat în Laravel. Este implementat foarte standard: există controlori familiare cu acțiuni, un nivel separat cu o vedere, folosind un motor de șablon și tot ceea ce se înțelege prin model.
O acțiune simplă în controler ar putea arăta cam așa:
ORM Eloquent vs. Doctrina ORM
Destul de o sarcină standard pentru dezvoltarea web este de a salva obiecte în baza de date și de a citi din baza de date. Pentru a lucra cu baza de date, se folosesc așa-numitele Modele. În Laravel, procesul de lucru cu baza de date este realizat prin intermediul ORM Elocvent.
Elocvent utilizează modelul Active Record, care este mult mai simplu decât modelele DataMapper, Unitatea de lucru și Tipurile de identitate. Acestea din urmă sunt folosite în doctrina ORM, care este ORM de bază pentru Symfony. Lucrul cu Elocvent datorită simplității sale are multe avantaje. Poate cel mai important: laconicitatea în descrierea modelelor și ușurința utilizării în cod. Atunci când creați un model, nu este necesar să descrieți fiecare accesoriu, este suficient să vă referiți la proprietate prin numele câmpului din baza de date.
Exemplu de lucru cu elocvent (din documentația oficială):
Există, de asemenea, mai multe opțiuni convenabile, cum ar fi un generator integrat de migrare sau o descriere simplă a relațiilor dintre modele. În general, Eloquent este convenabil pentru dezvoltarea unui model de dimensiuni mici și mijlocii. Cât de mult este potrivit pentru lucrul cu un model mare este greu de spus, dar pot să presupun că puterea lui poate să nu fie suficientă.
Artisan vs. Comenzile consolă
La fel ca în aproape toate cadrele moderne, Laravel are un instrument puternic pentru a lucra cu consola. În Laravel, această componentă este numită Artisan (artizan, maestru). Oferă oportunități ample de a efectua diverse operațiuni de rutină. În general, generatoarele de coduri sunt concentrate acolo (migrații, modele, controlori, ascultători și alții). Folosind artizan, puteți gestiona cozi de sarcini, efectua operațiuni programate, cache-uri clare și multe altele. În plus, este foarte ușor să vă scrieți propriile echipe. Pentru a face acest lucru, trebuie să creați o clasă de comandă și să o înregistrați. De asemenea, puteți crea lanțuri din comenzi, chemându-le una de cealaltă.
De exemplu, dacă vrem să creăm un nou model, atunci trebuie să executați următoarea comandă în consola:
$ php artisan face: model User
Artisan diferă puțin de componentele consolei standard din alte cadre. Este important să știm că există și funcționează. Echipa mea preferată este php artisan inspire :).
Container de servicii
După cum am menționat mai devreme, arhitectura Laravel este construită pe baza modelului Container de servicii. În general, implementarea sa este foarte asemănătoare cu implementarea în Symfony, deși există unele diferențe minore.
Când lucrați cu Symfony, încercați să respectați acest model și să extindeți dependențele chiar și prin straturi complexe de abstractizare. Întregul cadru este construit pe idiomul serviciilor și nu este întotdeauna posibil să primiți direct un obiect de o anumită clasă, trebuie să accesați serviciile corespunzătoare pentru ao obține.
Laravel în această privință nu este atât de zamorochen. Dezvoltatorul în ansamblu și-a dezlegat mâinile și am reușit să întâlnesc câteva exemple despre metodele sau obiectele necesare obținute prin apeluri prin interfețe statice. În general, aceasta este o încălcare a principiului șablonului, dar nu există nimic criminal în acest sens, este deja o problemă de gust și de abordare a dezvoltării.
Templating: Blade vs. crenguță
Vederea este implementată pe baza motorului șablon Blade. Acesta este un șablon regulat. Există operatori încorporați (cum ar fi), este posibilă redefinirea părților de șabloane, generatoare convenabile pentru obținerea de blocuri html, puteți accesa serviciile necesare, puteți chiar să vă scrieți propria directivă.
Blade mi sa părut mai puțin convenabil decât Twig. Deși cadrul Laravel ca întreg este mult mai simplu decât Symfony, este motorul șablon Symfony, care, după părerea mea, pare mai ușor de stăpânit.
Depistarea și gestionarea erorilor
În Laravel există un mod de dezvoltare, în care un panou special pe fiecare pagină devine disponibil dezvoltatorului. În panou, puteți vedea ce sa întâmplat în partea laterală a cadrului pentru a forma răspunsul serverului. De exemplu, puteți vedea o listă de interogări executate în baza de date, excepții, e-mailuri trimise și multe altele. Panoul este foarte asemănător cu panoul de depanare al Symfony, dar pierde și în mod semnificativ la putere.
Putem spune că creatorii cadrului Laravel au avut grijă de dezvoltatori suficient: în afară de depanarea panoului, sistemul poate loga tot ceea ce se întâmplă în el, există autoagenți de cod. Există, de asemenea, o funcție specială numită dd pentru a genera un număr de date în timpul procesului de dezvoltare pe ecran.
În general, impresia generală a muncii industriale cu cadrul Laravel a rămas bună. În ceea ce privește viteza de dezvoltare, poate fi semnificativ mai mare decât atunci când lucrați cu Symfony. Simplitatea cadrului și relativa laconicitate reduc foarte mult timpul necesar pentru scrierea directă a codului. În acest cadru există multe chifle care fac viața mai ușoară pentru dezvoltator, dar oferă și un bun impuls.
Pentru a instala cadrul și a lucra cu biblioteci terțe, este utilizat compozitorul, astfel încât instalarea și actualizarea bibliotecilor externe nu este deosebit de dificilă. În mod separat, ar trebui să acordați atenție performanței lui Laravel. Cadrul este simplu și, prin urmare, în mare parte rapid. Nu am folosit niciun punct de referință special, dar pe senzații și priviri rapide la panoul de depanare (oh da, puteți vedea totuși timpul total de funcționare al scenariului), avantajul de viteză este evident.
Un pic dezamăgit de documentație. Deși este prezentat, dar într-o formă foarte limitată. Cred că atunci când a fost făcut, dezvoltatorii au fost ghidați de același principiu al minimalismului ca și în construcția cadrului. Acesta acoperă doar funcționalitatea de bază, iar restul de minuni ale cadrului ar trebui investigate de dvs. sau căutate pe Internet. Este bine că Laravel este foarte comun și are o comunitate mare - aproape orice problemă pe care o veți întâlni a fost de mult hotărâtă de altcineva.
În cele din urmă, doresc să adaug că cadrul (este necesar să se acorde credit dezvoltatorilor săi), în practică, se dovedește exact așa cum este poziționat. Acesta este un instrument simplu și convenabil pentru "maeștri" în acele cazuri când nu trebuie să lovească toate întreprinderile dificile.
Trimiteți-le prietenilor: