Witam.

Mam pytanie do wymiataczy Symfony2 - jak pobrać jakąś usługę poza kontrolerem ?
Przeszukałem całą dokumentację, pogrzebałem w "wujku goolge" i znalazlem tylko jedno niezbyt ładne rozwiązanie poprzez globalną zmienną $karnel

Kurde taka prosta sprawa w tymi usługami, a tak "glupio" rozwiązana w tym frameworku

Pytanie czym jest Twoje "coś" co nie jest kontrolerem?

Zakładam, że jest serwisem, to stosujesz Dependency Injection i jako argument Twój serwis przyjmuje ten drugi serwis. Jeżeli jest komendą, to rozszerzasz klasę ContainerAwareCommand gdzie masz dostęp do Container i get'em pobierasz sobie service.

Symfony2 ma to świetnie rozwiązane, a DI jest bardzo sensowne, a nie głupie

Ogólnie tak jak Damonsson napisał, ale polecam przejrzeć dokumentację z różnymi przypadkami tutaj: http://symfony.com/doc/current/book/servic...ecting-services

Jest jeszcze sposób, że odwołujesz się bezpośrednio do Service Container, ale to są bardzo sporadyczne przypadki i raczej nie poleca się ich używać.

OK.

Chodzi mi dokładnie o dostanie się do 'doctrine.orm.entity_manager' żeby sobie pobrać potrzebne mi dane z bazy z tym że chciałem to zrobić w osobnej klasie która nie jest rejestrowana jako usługa.

Buduje sobie jakiś obiekt na zasadzie kompozycji składający się z innych obiektów, i właśnie w jednym z tych obiektów "podrzędnych" chcę się dostać do bazy...

Czyli rozumiem że wszystkie te klasy składające się na dany obiekt powinienem rejestrować jako usługi i wstrzykiwać do nich referencje na inne serwisy ?

A z tym że to jest głupio rozwiązane to miałem na myśli że taka usługa powinna być dostępna poprzez DI w każdym miejscu aplikacji, a nie tylko w kontrolerze

Nie prawda, tak jak jest teraz jest dobrze i prawidłowo.


Tworzysz w controllerze nowy obiekt i przekazujesz mu doctrine manager. W czym masz problem?

No nie wiem może ja robię coś źle :/

Jak najbardziej może być tak jak piszesz że mogę z kontrolera przekazać managera do danego obiektu z tym że w tym drugim obiekcie mam referencję do innego obiektu (tworzonego w konstruktorze tego pierwszego) z którego to własnie potrzebuję dostać się do bazy.

Czyli musiał bym przekazywać DoctrinManager'a dwa poziomy w dół, a to mi się nie za bardzo podoba ?

A czemu by nie? Swoją drogą, jak coś się zaczyna sypać, to widocznie aplikacja była źle zaprojektowana pod framework

1. Używanie DIC-a w kontrolerach (czy ogólnie) mimo iż powszechną jest złą* praktyką.
2. Jeżeli jakiś obiekt wymaga do swojego działania innych, powinien mieć je przekazane w konstruktorze - koniec, kropka. Praktycznie nie ma odstępstw od tej zasady. Następnie możesz się zdecydować, czy chcesz ręcznie tworzyć taki obiekt (przekazując mu wszelkie zależności) czy zrzucisz dokładnie to samo zadanie na DIC-a.

* przy niedużych, krótko rozwijanych projektach nie będzie to wielkim problemem, ale jeśli stawia się na jakość już tak.

Ja robie w ten sposób:

- Tworze kontroller w stylu (Przykładowe zapisywanie danych w bazie, wraz z walidacja w serwisie):

[PHP] pobierz, plaintext 
 
public function someController(Request $request)
{
        $data = $request->request->all();
        list($entity, $form) = $this->get('some.service')->create($data, false);
 
        // return $this->render( //...
}
[PHP] pobierz, plaintext 

w tym some.service jest obsługiwany formularz, walidowane są dane i zwracane ewentualne informacje w postaci flashBaga.
Ja lubie zasade "chude kontrolery" więc mniej więcej taki work flow obieram

Jako DI do service wstrzykuje tylko to co potrzeba - czasami repository (również jako service je robie, link poniżej podaje), czasami jakiś urlGenerator czy np. flashBagi, form creator itp.

http://php-and-symfony.matthiasnoback.nl/2...entity-manager/

OK. Dzięki Panowie za rozjaśnienie sytuacji

Po pierwsze, jest to łamanie świętych zasad SOLID.

Poza tym widać, że książki do Symfony to nawet nie widziałeś na oczy - jest w niej jasno napisane, że aplikacja powinna być całkowicie niezależna od frameworka, a nie pisana pod framework (sic!).
Jest nawet wspomniane to, aby Doctrina nie przekazywać do żadnych klas biznesowych, bo uzależni to biznes od frameworka.

Bazę w klasach powinno obsługiwać repozytorium (a nie Doctrine), które można sobie wstrzyknąć do danej klasy.

Jeśli kolega tutaj ma jedną klasę, która zarządza innymi, to wystarczy zrobić tą "główną" klasę jako serwis, następnie wstrzyknąć do niego wszelkie zależności.
Jeśli jakaś z zależności wymaga dostępu do bazy, to robimy ją jako serwis, wstrzykujemy repozytorium i wrzucamy do "serwisu zarządzającego".

To najprostsza droga do uzyskania w miarę dobrego poziomu decouplingu, są też inne ciekawe rozwiązania "architektury cebulowej", ale raczej
nie ma sensu w tym wypadku się nad nimi rozwodzić.