🚀 go-pugleaf

W dniu wtorek, 13 marca 2018 15:04:00 UTC+1 użytkownik immo napisał:

> Poza tym - nie rozumiem o co Ci chodzi :) Chyba że o to, że koniec końców w aplikacji widoczne jest to jako obiekt który ma w sobie obiekty :P

Różnica jest zasadnicza:
- w Twoim podejściu zależności są zaszyte w kodzie, co znakomicie utrudnia, jeśli nie uniemożliwia zarządzanie nimi - np. bez 100% pokrycia kodu testami możemy nie wiedzieć, że kod używa zależności, która nie jest spełniona,
- przy użyciu mechanizmów DI zależności są zadeklarowane w interfejsie klasy np. jako parametry konstruktora, co jest przejrzyste i pozwala na automatyzację, ale jest też bezpieczniejsze - zależności są rozwiązywane w momencie tworzenia instancji klasy.

Do tego dochodzą takie kwestie, jak np. możliwość zmiany modelu czasu życia usługi - jedna zmiana w konfiguracji i zamiast singletona, mamy instancję serwisu per klient, jeśli akurat zajdzie taka potrzeba.

> Przeczytałem i nadal nie rozumiem. Pomijając kwestie interfejsów oraz usług i DI to całą reszta mniej więcej dokładnie opisuje to co mam.
> 
> Przecież nie będę tłumaczył że jest to framework niezależny od jakiejkolwiek aplikacji gdzie na podstawie konfiguracji dostarczanej mu z dowolnego miejsca niejako buduje sobie aplikacje i sposób jej działania?

Wszystko pięknie. Pytanko: czy przypadkiem nie dostarczasz zawsze kompletu usług frameworka, niezależnie od tego, jaki podzbiór 'pluginów' jest wybrany do danego wdrożenia - niezależnie od tego, czy dana usługa faktycznie jest użyta przez którykolwiek plugin?

> Dlatego chce mieć singletona bo nie ma potrzeby żeby była więcej niż jedna instancja frameworka (bo to nawet niewskazane), chce mieć wszystko usystematyzowane i poukładane, tak aby dostęp do podstawowych 'niezmiennych' funkcjonalności był jednakowy. Rozszerzenia logiki dostępne przez dllki, formy generowane przez fabrykę na podstawie metadanych...

Nie znam lepszej formy na 'usystematyzowanie i poukładanie' zależności w kodzie niż zautomatyzowanie tego zadania za pomocą kontenera IoC.

> > ...a singletony to zło. W systemie powinien być tylko jeden singleton: kontener IoC.
> 
> Zło a jednak sam to proponujesz :) Nie ma znaczenia czy dla kontenera IoC czy dla czegoś innego. Zresztą, ja już pisałem że to jest strasznie uproszczone dla potrzeb pokazania tutaj samego schematu działania a nie tego jak to faktycznie jest zrobione. I to tylko kwestia nazewnictwa czy Ty to nazwiesz kontener IoC w którym trzymasz wszystko, czy ja to nazwę Core i trzymam dokładnie to samo.

To nie ja proponuję, tylko JAKIŚ stan globalny w programie zawsze będzie. Im go mniej, tym lepiej.

Kontener ma tą przewagę nad Twoim Core, że jego struktura jest dynamiczna, przyjmie wszystko - oraz że kontener jest raczej bytem 'z boku', który tylko łączy ze sobą klocki, a nie punktem dostępowym do funkcjonalności frameworka - nigdy nie powinno być potrzeby jawnego odwoływania się do kontenera z poziomu serwisów ani klientów.

> pozdrawiam,
> Przemek O.

Pozdrawiam,
Virion