Conexiunea as pune-o in containerul de servicii, ofc, preluata ca singleton in UserRepository, sau, daca sistemul imi permite, as injecta-o direct in ctorul de UserRepository, cu… wiring singleton (nush cum altfel sa spun aici :D).
Oribil. Vomit.
De ce? Ai instantia de fiecare data?
Exista o duzina de articole si carti care vorbesc despre singleton, despre cum violeaza testabilitatea si SOLID.
Esti baiat mare, te poti documenta.
De instantiat as instantia o singura data.
Si cum instantiezi o singura data daca business-ul tau in acel controller, de ex, va folosi 3 repositories, fiecare avand nevoie de conexiunea db?
Cum adica cum? Cu new.
Esti simpatic. Am sa raspund eu pt tine: "instantiez o singura data, apoi il preiau din container cu get('db')". Este ca asta ai fi spus?
Daca este, atunci franeaza-ti emeticele, fiindca si eu tot asta spuneam. “preluata ca singleton”, remember? Sau tu crezi ca un DiC nu e un “registry pattern”/stare globala/singleton?
Sper ca acum te simti mai bine.
E irelevant ce e acel registry in afara modelului si de unde vine conexiune, in model nu ajunge niciun DiC.
Din punctul de vedere al modelului, registry nici nu exista.
DiC e registry, dar DiC nu este un singleton, si nici global state. Ma rog, tu poate te gandesti la o anumita implementare care este, dar nu trebuie sa fie. Sau poate te gandesti ca folosesti o singura instanta de DiC in tot proiectul, dar asta nu il face pe acel DiC global - il poti inlocui in orice layer fara a afecta alte subsisteme.
Pai… eu credeam ca o singura instanta este definitia “registry” si a obiectului global. Nu faptul ca poti sa schimbi acel obiect il face global (si global $var poate fi schimbat in orice layer, nu?), ci faptul ca-i accesibil de oriunde. Si cand intr-un registru poti stoca o instanta a unui obiect, hello singleton. Numai ca nu chemam getInstance(), deci e ok. 
Nu stiu daca-i o idee buna ca un DiC sa NU fie global state. Ce cross-cutting manager mai e si ala? Si nu fi dogmatic in privinta singleton-ului. Da, stiu mantra cu singleton, dar aia-i pt noobi, nu pt cei care stiu sa-l foloseasca.
Testabilitate.
Si nu poti avea configuratii/wiring-uri diferite per environment?
Ok, ok, fuck it.
Mor de curiozitate: tu folosesti un DiC care NU este global? Cum il injectezi in chestii? Il instantiezi - cu tot bootstrapping-ul lui sau alte configuratii - de fiecare data? Sau cum?
Il instantiez o singura data.
Read: http://www.davidarno.org/2013/11/13/are-ioc-containers-a-case-of-the-emperors-new-clothes/ (si articolele referentiate acolo)
Bineinteles ca pot avea configuratii diferite / environment. Ba chiar am un contract Environment.
Nu stiu ce ti se pare atat de incredibil. Folosesc corect polimorfismul.
Cred ca aceasta prezentatie iti va prinde bine:
Nu vad care-i treaba repository-ului, atata timp cat modelul inca face toata treaba in controller.
Eu as merge doar pe un active record si un DI cu automatic dependency injection.
use App\Models\User;
use Psr\Http\Message\RequestInterface;
class UserController
{
private $user;
public function __construct(User $user)
{
$this->user = $user;
}
public function signupAction(RequestInterface $request)
{
$created = $this->user->create($request->getParsedBody();
}
}
- Am injectat si request-ul, ca sa nu avem dependente de care inca nu stim.
- Si putina interoperabilitate ca nu strica.
@IonutBajescu - modelul face toata treaba in controller? Nu inteleg ce vrei sa spui. Motivul pt care de obicei aleg un nou serviciu sa se ocupe de CRUD este pt a scoate acea responsabilitate afara din Model, adica opusul active record-ului (care nu prea-mi place; User-ul tau deodata stie prea multe - stie si business, si persistenta). Fine, but don’t like it.
@flavius - hai bre nu-mi mai da youtube-uri si articole, ca n-am chef. Da-mi cod, nu-mi lectura, wtf.
După cum am zis
Adica, daca nu facem refactoring dupa cum ai zis tu, n-ai sa misti un deget? Eu zic sa scrii tot codul, ca nu-i mare lucru - apoi pornim de acolo. Vrei acuma sa scriem un cod dupa indicatiile tale? Ti s-au dat mai multe variante. Nu patze nici una?
Si chestia asta era mai buna in github, cu forkuri and shit. Fiecare scria in tihna lui, apoi am fi putut continua cu pedanteria aci, dand linkuri.
1 Like
Si eu i-am zis sa prezinte cod ca sa inteleg la ce se refera, am vazut ca a pus, desi in comentariul initial zicea o chestie, codul prezinta o situatie usor modificata. Inca sunt curios cum ar arata tot call stack-ul in viziunea lui la un request de genul POST /user/create username="John Doe" email="[email protected]" password="123"
Bine spus.
Ce scriu aici scriu pentru cine dorește ajutorul meu, nu pentru tine.
Există lucruri constructive care merită timpul, și lucruri care nu îl merită.
Ugh, ai mai zis faza cu “scriu pt cine vrea ajutorul meu”. Nu te inteleg, mister - vrei cerere explicita sau ce? Pune si scrie, ca zeci de oameni vor citi, indiferent daca o scrii pentru cineva sau nu. Sau zi ca nu vrei, n-o da pe zicale. Mai bine cod decat abramburelile noastre, eh?
Nu am nevoie de mătănii, am scris o parte din ce am avut de zis, cine consideră că are ceva de învățat din asta face refactoringul, iar eu văzând că acea persoană își dă interesul, depun și eu încă o bucată de efort în plus față de ceea ce am învestit deja.
E simplu, se numește risk management.
(de mâine sunt pe pârtia de ski, nu mai stau la calculator, doar pe mobil uneori)