În această postare, voi arăta cum să refactorizați aplicația tutorial Slim pentru a urma mai atent modelul Action-Domain-Responder.

fiecare acțiune

Un lucru frumos despre Slim (și majoritatea celorlalte cadre de interfață utilizator HTTP) este că acestea sunt deja orientate spre „acțiune”. Adică, routerele lor nu presupun o clasă de controler cu multe metode de acțiune. În schimb, ei presupun o închidere a acțiunii sau o clasă invocabilă cu o singură acțiune.

Deci, partea Action din Action-Domain-Responder există deja pentru Slim. Tot ce era necesar este să scoți biți străini din acțiuni, pentru a separa mai clar comportamentele de acțiune de comportamentele de domeniu și de răspuns.

Extrageți domeniul

Să începem prin extragerea logicii domeniului. În tutorialul original, Acțiunile utilizează direct două mapere sursă de date și încorporează și o logică de afaceri. Putem crea o clasă Service Layer numită TicketService și putem muta acele operațiuni din Acțiuni în Domeniu. Făcând acest lucru ne oferă această clasă:

Creăm un obiect container în index.php astfel:

Și acum Acțiunile pot utiliza TicketService în loc să efectueze direct logica domeniului:

Un avantaj aici este că acum putem testa activitățile domeniului separat de acțiuni. Putem începe să facem ceva mai mult ca testarea integrării, chiar și testarea unitară, în loc de testarea sistemului end-to-end.

Extract Responder

În cazul aplicației tutoriale, lucrarea de prezentare este atât de simplă încât nu necesită un răspuns separat pentru fiecare acțiune. O variație relaxată a unui strat de răspuns este perfect potrivită în acest caz simplu, în care fiecare acțiune utilizează o metodă diferită pe un răspuns comun.

Extragerea lucrărilor de prezentare către un răspuns separat, astfel încât crearea răspunsului să fie complet eliminată din acțiune, arată astfel:

Apoi putem adăuga obiectul TicketResponder la containerul din index.php:

Și în cele din urmă ne putem referi la Răspuns, în loc de doar sistemul de șabloane, în Acțiuni:

Acum putem testa lucrările de construire a răspunsurilor separat de lucrările din domeniu.

Punerea tuturor răspunsurilor într-o singură clasă cu mai multe metode, în special pentru cazuri simple precum acest tutorial, este bine să începem. Pentru ADR, nu este strict necesar să aveți un răspuns pentru fiecare acțiune. Ceea ce este necesar este să extragem din acțiune problemele legate de construirea răspunsului.

Dar pe măsură ce complexitatea logicii de prezentare crește (negociere de tip conținut? Anteturi de stare? Etc.) și pe măsură ce dependențele devin diferite pentru fiecare tip de răspuns construit, veți dori să aveți un răspuns pentru fiecare acțiune.

Alternativ, s-ar putea să rămâneți cu un singur răspuns, dar să reduceți interfața acestuia la o singură metodă. În acest caz, puteți constata că utilizarea unei sarcini utile de domeniu (în loc de rezultate de domeniu „gol”) are unele beneficii semnificative.

Concluzie

În acest moment, aplicația tutorial Slim a fost convertită în ADR. Am separat logica domeniului la un TicketService, iar logica de prezentare la un TicketResponder. Și este ușor de văzut cum fiecare acțiune face aproape același lucru:

  • Mareșalii intră și îl transmit în Domeniu
  • Obține înapoi un rezultat din domeniu și îl transmite răspunsului
  • Invocă răspunsul, astfel încât să poată construi și returna răspunsul

Acum, pentru un caz simplu ca acesta, utilizarea ADR (sau chiar MVC webbishy) ar putea părea exagerată. Dar cazurile simple devin complexe rapid, iar acest caz simplu arată cum separarea ADR poate fi aplicată pe măsură ce o aplicație bazată pe Slim crește în complexitate.