[Symfony][Symfony2] Dependency injection container Opcje

[Orzeszekk]

Do czego on tak naprawdę służy?

Z tego co zrozumialem to ma on zlikwidowac problem ze gdy zmieniamy nazwe klasy to musimy zmienic x nazw w kodzie, oraz pozwala oddzielic singleton od jego implementacji (niby mamy taki singleton, tworzony raz, dostepny globalnie ale jak chcemy to mozemy utworzyc jego obiekt recznie na potrzeby testu jednostkowego i nawet cos tam wstrzyknac jakies parametry w konstruktor?). No i po za tym jest wg mnie mało wygodny w uzyciu bo musimy wpisywac nazwy stringami w ktorych mozemy sie pomylić (literówka) i żadne IDE nam nie wskaże takiego błędu, a SF z jakiegos powodu nie chce uzywac stałych, tylko zamiast tego uzywa stringow.

Klasa dependency injectora nie jest chyba zbyt duza, a poswiecono jej bardzo obszerny rozdzial w ksiazce, no i na potrzeby DI stworzono całą konfiguracje w Yamlu ktora wyglada jak nowy jezyk programowania.

Czy do czegos jeszcze sie przydaje ten dependency injection container? Czy wprowadza jakąś dużą innowacje do kodowania (duzo ludzi sie nim zachwycalo) czy to po prostu taki testowalny singleton?

[Orzeszekk]

Czyste PHP w symfony2 jest z lekka szalone, ma taka renundancje ze i tak trzeba yamla uzywac nawet jak go ktos nie lubi.


Czyli ten DIC to zamiast "hardkodowac" sobie w projekcie 10 razy linijke kodu $mailer = new MyMailer();, lub co gorsza, $mailer = MyMailer::get(); tworzę wytwór jakim jest $mailer = $this->get('my_mailer'); a w configu symfony ustawiam my_mailer: { class: "MyMailer" } czy jak tam sie to pisało, i jesli chce mi sie zmienic mailera to po prostu zmieniam go w configu a nie po kolei we wszystkich miejscach? To jest ta główna korzysc tak?

skoro symfony2 to w zasadzie kompilator PHP to nie widze powodu dla którego nie mogłby wygenerowac w jakims pliku php inkludowanym w bootstrapie wszystkich stałych z nazwami moich serwisów, żebym mógł sobie w IDE wpisać SERVICE_... a ono by mi uzupełniło, i co ważniejsze wyłapało głupie literówki. wiem ze stałe to zbedny overhead ale literówki to rowniez overhead tylko ze predkosci pisania ,a skoro symfony tak bardzo integruje sie z APC to zawsze tam mogloby zapisac set stałych z nazwami serwisów co spowodowaloby ze tylko raz bylyby tworzone.

oddzielic singleton od implementacji - znalazlem na stronie z jakimis refaktoryzacjami porade ze jesli juz musisz uzyc singletonu to by część "pracującą" wrzucić do jednej klasy, której instancje mozna stworzyc normalnie na potrzeby unit testu, i stworzyc druga klase opakowujaca tego workera w singleton, ktory bedzie sobie normalnie dzialal w programie. o to mi chodzilo.

no i przy automatycznych zmianach nazw wszystkie IDE do php sie czasami mylą, nie ma idealnego pod tym względem. a znajdz/zamien potrafi narobic sporo bałaganu (IMG:style_emoticons/default/smile.gif)

Ten post edytował Orzeszekk 5.02.2012, 20:40:29

[ano]

Czyste PHP w symfony2 jest z lekka szalone, ma taka renundancje ze i tak trzeba yamla uzywac nawet jak go ktos nie lubi.

Co ma yaml do 'redundancji'? ;] Poza tym, kto Ci broni pisać wszystkie configi jako *.php? Jeżeli, Ci tak wygodniej to zamiast yamla/xmla pisz php...

Co do podpowiadania 'magicznych rzeczy' to może zainteresuje Cię ten plugin do Eclipse: http://symfony.dubture.com/ .
Potrafi naprawdę sporo!
- Podpowiada serwisy (Controller::get('...'))
- trasy w routingu (również w czasie tworzenia kodu twiga {{ path(...) }} )
- a nawet ścieżki do szablonów (Controller::render(...));.
- i jeszcze trochę (IMG:style_emoticons/default/wink.gif)