On 23.06.2011, at 21:25, Johannes Heinen wrote: > 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 ...
If you assume that controllers will never be provided to a 3rd party, one could make the argument pro service locator, aka injection the container. However even if all controllers were maintained by me (or my team) I still would not be very happy to not have easy access to the dependencies of my controllers come the day I need to do some refactoring. Furthermore I think that there are use cases where one infact would want to share a controller with a 3rd party (actually not even a 3rd party, just another application) and at that point it will not be practical anymore to use a service locator because hardcoding the dependencies inside my controller will limit my ability to reuse that controller because of differences in the service naming across applications. For example a controller I want to add to my application may be referencing the "templating" service assuming its aliased to the twig templating service while in the rest of the application I am using a templating service referencing the php templating service. Furthermore to make matters worse, controllers are the extension point for most application specific logic. This means if my controller relies on a service locator I am screwed if I ever need to adjust anuthing. Where as if a service used by a controller service uses service locator, I can solve the issue by simply defining a new service and injecting this new service into my controller service. In other words, imho using anything but services for controllers is a huge problem, where as its less of a problem in a service used by a controller. regards, Lukas Kahwe Smith [email protected] -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
