Vlákno názorů ke článku Dependency Injection ještě jednou :-) od kvr kvr - ... nechal jsem si to projít hlavou, co...
-
... nechal jsem si to projít hlavou, co na to napsat, takže trochu pozdní reakce...
Z velké části tady mícháte jabka s hruškama, co je container, co je DI, atd, to už napsal někdo výše.
Jak jsem psal u předchozího článku - vy tam DI defakto máte, akorát řešené svérázným způsobem a implementované pomocí globálních proměnných v rámci datového objektu (neviděl jsem implementaci Product, takže nevím, jestli je tam problém navíc, že jde přímo do DB nebo je tam ještě abstrakce nad tím). Tak jako tak, důsledkem je, že nelze například separovat Product od konkrétní repository, bez toho, aby aplikační kód přenastavoval dependency za běhu. Což znamená (nejen tady), že runtime konfigurace závisí na aplikačním kódu, místo, aby to bylo opačně - což přirozeně znemožňuje nebo komplikuje customizaci a reusability. O testech ani nemluvě (ale ty asi půjdou v Php nějak řešit). Kromě toho je značně nejasné, jaké jsou další zodpovědnosti Product, pro které musí mít další procesní i datové závislosti.
Z jednoho komentáře, jestli používat ini/json/native code. Ano, php kód bude asi nejrychlejší, to ale přímo neovlivňuje DI samotné. Hesla by třeba neměla být ani součástí kódu ani jiné konfigurace lokální - ideálně by měla autentifikace přes role nebo uložena v secret storage, pokud daná technologie podporuje jenom password authentication (viz třeba AWS Secrets Manager). Ohledně performance - v Java to je třeba naopak - JSON a XML budou rychlejší než Java konfigurace - pro benchmarks viz třeba https://github.com/kvr000/zbynek-java-exp/tree/master/benchmark/deserialize-benchmark/ , Java tam z nějakého důvodu chybí, ale byla značně pomalejší). Výhodou konfigurace v kódu (a důvod, proč ji většina moderních DI implementací podporuje a preferuje) je větší flexibilita, možnost implementovat podmínky apod, což je ve starém XML (Spring 2) dost komplikované. Ale v prvé řadě, pokud budu chtít řešit performance, tak nepoužiju Php :-D .
Ohledně výkonu DI - existují i compile time DI - například Dagger pro Java. Pokud budu chtít, udělám si DI v jakémkoliv jazyce manuálně - jednoduše si zavolám konstruktory ručně a předám jim dependencies na začátku aplikace - v C++ jsem to kdysi u některých projektů dělal - projekt měl nějaké jádro, které záviselo na platformově specifických komponentách, případně na testovacích komponentách - to je zcela validní přístup. Nevalidní je, pokud si ty aplikační komponenty začnou dependence nastavovat samy.
Pořád píšete, že děláte na velkých projektech a chcete čísla. Tak zkuste napsat, jak velké ty projekty jsou (LoC), kolik komponent v nich je, jaké jsou závislosti. IMHO posuzujete na relativně malém projektu REST+SQL+nějaké third party, kde jsou ty závislosti nejspíš poměrně jednoduché. Pro srovnání, teď dělám na projektu, který má hodně přes milion řádku (záměrně nechcu být ani řádově konkrétní) jenom v části Java, 150 externích third party knihoven (řekněme reálně 20 z top level), desítky DI modulů. Tento týden jsem opravoval DI hell vzniklé přesně podceňováním DI patterns po dobu několika let, což znamenalo 500 změněných aplikačních modulů a testů. Stálo to spoustu času a peněz, ale vliv na budoucí vývoj je nevyčíslitelný.
