Symfony wstrzykiwanie zależności.

Cześć mam mały problemik.
Czytam sobie dokumentację symfony i wszytstko fajnie aż dochodzę do pewnego momentu gdzie nie mam pojęcia co z tym zrobić.
Strona z dokumentacją : http://symfony.com/doc/current/controller/upload_file.html
Mam następujący kod.

public function newAction(Request $request, FileUploader $fileUploader)

Czy może mi ktoś powiedzieć jak wstrzyknąć FileUploadera do akcji?
Próbowałem zarejestrować kontroler jako serwis w następujący sposób:

services:
    wave_dev_invoice_reader.upload_file:
        class: WaveDev\InvoiceReaderBundle\Service\FileUploader
        arguments: ["%invoices_directory%"]

    wave_dev_invoice_reader.default_controller:
        class: WaveDev\InvoiceReaderBundle\Controller\DefaultController
        arguments: ['@wave_dev_invoice_reader.upload_file']

route:

wdir_process_image:
    path:   /process-image
    defaults: { _controller: wave_dev_invoice_reader.default_controller } # czy też z wywoaniem konkretnej akcji

Kontroler zostaje wywołany, ale nie zostaje do niego wstrzyknięty żaden obiekt.

Małe sprostowanko. Z rejestrowaniem kontrolera jako serwis dobrze kombinowałem (jednak działa, rombnołem się troszkę). Ale tracę przy tym $container i nie mogę korzystać z metody get().

bo Ci ta metoda nie jest potrzebna. W robieniu kontrolerów jako serwisy chodzi o to, by nie przekazywać tam całego kontenera :)

zrób konstruktor, w którym zdefiniujesz zależności i podczas rejestrowania go wstrzyknij tam zależności. Nie będziesz wtedy potrzebować metody $this->get() w kontrolerze.

Czaję, a przy okazji. Czytałem dokumentację do nie właściwej wersji sf. I nie mogłem garnąć w jaki sposób jest wrzucany dodatkowy argument do akcji :D. I kombinowałem troszkę jak koń od górę.
Zdarzyło ci się kiedyś zmieniać kontrolery na serwisy? W jakich sytuacjach to robiłeś?

to zależy od sytuacji. Przykład: masz eksport listy zamówień/produktów/postów do kilku formatów xml/csv/coś_tam_jeszcze. Rejestrujesz serwis-kontroler, który ma tylko jedną metodę exportAction(). Tworzysz interfejs dla wszystkich tych typów eksportu i następnie 3 klasy, które będą te eksporty wykonywać.
Następnie, rejestrujesz 3 routingi do tych eksportów, ale dla każdego z nich do kontrolera wstrzykujesz inną zależność (tzn. klasę, która odpowiada za eksport). Dzięki temu w kontroler jest maksymalnie pusty (konstruktor, jedna zmienna z klasą do eksportu xml,csv etc oraz akcję exportAction()). Kolejne typy eksportu to implementacja ww interfejsu i podpięcie do tego routingu.

Podsumowując: ExportInterface,
XMLExport implements ExportInterface
CSVExport implements ExportInterface
// ...

następnie tworzysz ExportController, który w konstruktorze ma zależność do ExportInterface. Rejestrujesz tyle serwisów z ExportController ile masz formatów eksportu (każdy ma w sobie inną implementację ExportInterface
Kolejno, dla każdego eksportu robisz coś na wzór tego: http://symfony.com/doc/current/controller/service.html

@no_solution_found: Ja zrozumiałem,ale tak szczerze, równie dobrze można zrobić 3 akcje w kontrolerze i mieć to samo. Nie masz interfejsów, dodatkowych klas itd. Zgodność z zasadami w miarę zachowana bo kontroler tylko wykonuje metody exportu a nie robi czegoś innego. Więc jaka jest zaleta tworzenia serwisu?

powtarzasz kod w kontrolerze. W takim wypadku jak wygląda np testy? W kontrolerze testujesz 1 metodę. Masz do tego 3 mniejsze klasy, które potestujesz jednostkowo. Wyobraź sobie, że dla każdego eksportu robisz akcję w kontrolerze. Jest ich 10. Dla każdego eksportu do kontrolera wstrzykujesz zależności. Widzisz już z czym zacznie się robić problem? By wyeksportować do csv wstrzykujesz niepotrzebnie wszystkie inne zależności, budowane są serwisy, które zupełnie nie są potrzebne itp.

Jak pisałem wcześniej, to wszystko zależy do potrzeb i problemów :)

Chodzi ci o to, że tworząc 10 akcji kontrolera (eskportów) a przy tym zamiast stworzyć serwis rozszerzam bazowy kontroler, wstrzykuję wszystkie zależności? (no bo je przetrzymuje kontroler bazowy, typu managera doctrine, renderowanie widoków itd)

Po prostu jako tako na razie nie widzę w ogóle zalet w używaniu serwisów. Być może to za małe doświadczenie w symfony.

możliwe, albo brakuje dobrego przykładu. Szukałem na oficjalnym blogu symfony dobrego przykładu tego podejścia, ale oni to tam opisali bardzo ogólnie i minimalistycznie.
Dzieląc jedną klasę na mniejsze ułatwiasz sobie późniejsze utrzymywanie oraz testowanie, bo masz do przetestowania 10 małych klas a nie jedną wielką z dziesiątkami zależności. Albo do parametrów funkcji dopisuje się kolejne argumenty co powoduje, że zaczynają robić się potwory
Myślę, że bardzo dobrym antypaternem jest ta klasa https://github.com/Setasign/FPDF/blob/master/fpdf.php