Continuăm să ne plimbăm în design și dezvoltare. În ultimul articol despre proiectarea entităților de domeniu, am compilat o entitate completă-agregată a domeniului Subiect cu propria sa logică de afaceri pentru a descrie obiectele angajaților. Acum trebuie să lucrăm cumva cu el de la operator, să îl salvăm în baza de date și să-l înapoi. Dar angajatul nostru nu conține o singură linie pentru a lucra cu baza de date, așa că nu știe să se salveze. Ce să faci cu asta?
În mod normal, în acest caz, creați un obiect de depozitare extern care va gestiona persistența entităților în aproximativ următoarele moduri:
Și este acest EmployeeRepository pe care îl putem folosi în locurile potrivite. De exemplu, în serviciile aplicației. Ce fel de servicii sunt și ce fac ei?
Serviciul de aplicații
Tot codul scris în controler este incomod. Motivele pentru aceasta vor fi discutate mai jos. În schimb, există o practică populară în cercurile înguste de cod pentru a extrage logica de la controler în clase separate, numite servicii la nivel de aplicație (sau servicii de aplicație), și a le accesa de la controlori. Mai ales că nu vom intra în terminologie, ci doar să vedem ce este.
În cazul nostru, pentru a interacționa cu controlorii de browser sau API, vom avea nevoie de un serviciu de aplicații numit EmployeeService. care utilizează depozitul EmployeeRepository și managerul evenimentului EventDispatcher va efectua toate operațiunile pe entitatea angajatului:
Putem transfera un număr mare de parametri pentru fiecare metodă:
Dar pentru a nu deveni confuzi în ordinea și cantitatea lor, am asamblat aceste seturi în structuri separate de transfer de date (Data Transfer Object) cum ar fi AddressDto:
După ce au învățat intens despre Zen pe PLO, mulți au fost rugați să facă ceva mai important în cadrul Yii2 pentru a aplica noile cunoștințe în practică. Și chiar pe forum au menționat că mă așteaptă de la cursul de pe acest cadru. Așa cum am promis în blog, vom lansa în curând o mare clasă de masterat multi-zi pe dezvoltarea unui magazin online pe Yii2 folosind cele mai bune practici.
Deci, să continuăm! Am învățat deja puțin cum să proiectăm entități în prima parte și chiar am pregătit un serviciu de aplicații mici în al doilea. Și am fost de acord că trebuie să facem un depozit pentru stocarea entităților de domeniu în baza de date. Și chiar și-a făcut emulatorul de testare și a pregătit teste de lucru. Înainte de a studia orice soluții gata făcute astăzi, vom bicicliza implementarea proprie a depozitului, fără a utiliza sisteme ORM de la terți.
Unii dezvoltatori uneori se întreabă cum pot fi programați pe cadre fără a utiliza CRUD și ActiveRecord și de ce o astfel de operație simplă "ușoară" cu câmpurile din baza de date nu-i plac munca-OOP-shniki. Și mulți oameni cer asta în testele pe care trebuie să le testezi și ce nu. Și dacă este necesar să verificați metodele private sau nu? Vom aborda aceste probleme.
Webinar-screencast despre compararea protocoalelor de apel la procedurile RPC la distanță, accesul la obiecte SOAP și arhitectura REST pentru implementarea API-ului pentru lucrul cu site-ul. Luați în considerare scrierea API-ului RESTFul pentru proiect pe Yii2 Framework și testarea acestuia folosind Codeception.
Și ce trebuie să faceți în cazul unor astfel de lucruri
Controlerele trag numai EmployeeService. Este al nostru și este un set de cazuri de yuz care funcționează deja cu entități. Controlorul nu are acces direct la entități.
Mulțumesc. Cu plăcere am petrecut o jumătate de oră din viața mea, citind articolul tău.
Aștept cu nerăbdare să continuu!
Doar câteva întrebări:
1. Sunt autorizate obiectele pentru a face publice câmpurile? Este o încălcare a încapsulării?
2. Dacă serviciul are mai multe metode, de exemplu, UserService pe care l-ați descris. În unele metode aveți nevoie de passwordHasher, în unele nu există. Se pare că, pentru a apela metoda changeEmail, trebuie să trecem încă un obiect passwordhasher la constructor, care în acest caz nu avem nevoie. Ce se face, de obicei, în astfel de cazuri? Serviciul este împărțit în mai multe părți? Sau este folosit ca atare?
1. DTO este o structură de date (înlocuirea unei matrice asociative), mai degrabă decât un obiect complet.
2. În abordarea CQRS cu Command Bus, o clasă de instrucțiuni este scrisă pe instrucțiune (DTO). De exemplu, pentru comanda ProductCreateCommand, ProductCreateHandler este realizat, iar de la controler, toate comenzile sunt distribuite în magistrală ca aici și aici. Se dovedește mai mult cod, dar obiecte suplimentare nu se injectează. Prin urmare, fie separați în mai multe părți, fie nu vă faceți griji cu privire la extra jumătate kilobyte de memorie pentru PasswordHasher.
Și unde pot adăuga o tranzacție? Poate ceva similar în controler?
Trimiteți-le prietenilor: