Hi, you are definitively right, but see: the issue does not concern DIC managed classes but merely "access short cuts" for container aware implementations (like controllers).
In my opinion, defining controllers as services is only a "workaround" to fix the problem of providing commonly used dependencies (entity manager, mailer ...) without coupling the controller to an abstract base class (in fact it should be a plain, lightweight php callable) and to optimize the lookup (service-id insteand of classname/action- method combination). So, controllers ARE in fact services at the moment and by the current implementation, but actually shouldn't. They rather should be implementations of ContainerAware or "magically injected" by annotations. This is at least my understanding of this: http://martinfowler.com/articles/injection.html#DecidingWhichOptionToUse Technically, the problems mentioned above and at other resources stay: The "build" problem during development, run-time introspection of classes that are not managed by the DIC, no or only brainfucked lazy- loading workarounds ("getter-injections" or such crazy things). I am into the problem since a month or so and just noch the expert, but each solution is a compromise until now - i had not found the best way by now ... On 23 Jun., 20:27, Lukas Kahwe Smith <m...@pooteeweet.org> wrote: > On 23.06.2011, at 20:22, Kris Wallsmith wrote: > > > > > > > > > > > I agree that there is too much configuration when setting up a controller > > service, but this won’t be an issue anymore once we’re able to define a > > service and its dependencies using annotations, as everything will be in > > one place. > > > /** @Service(“main_controller”) */ > > class MainController > > { > > /** @Service */ > > private $request; > > > /** @Service */ > > private $router; > > > /** @Service(“doctrine.odm.mongodb.document_manager”) */ > > private $dm; > > > /** @Route(“/“) */ > > public function homepage() > > { > > // ... > > } > > } > > annotations are not the silver bullet and we should never rely on them to > solve an issue. configuration is traditionally not separated from code > because there were no means to have them together, but because it simply > makes sense. for example defining your dependencies inside your code defeats > the purpose if dependency injection even if it can be overridden because then > you end up with a mess of false expectations. > > furthermore annotations can kill development performance as they keep causing > the config cache to trigger a refresh as you change files. > > so annotations are all nice, but they cannot be our sole answer to a real > world issue. > > regards, > Lukas Kahwe Smith > m...@pooteeweet.org -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
