On Dec 10, 2012, at 24:46 , Johannes Schmitt <schmitt...@gmail.com> wrote:
> Personally, I don't think it's a super idea. Most of the time, commands > should be lightweight. > > If there is too much code in a command, that's a good indicator to extract it > to a dedicated class (which then can be a service). This also makes code > easier re-usable as you decouple your code from the input/output interfaces. > Your tests will benefit from this as well. Well the same arguments apply here as they do for Controllers. yes many people might say that unit testing Commands/Controllers does not make sense anyway, rather make them lightweight and test their dependencies or use functional tests. And even that argument isnt clear cut. But of course there are several imho even more important reasons why using services for Commands/Controllers is useful: - all the reasons why DI makes sense (f.e. a slow migration from one implementation to another without having to change code you might not control by simply changing what is injected) - having a central location via the DIC that tells you what Commands/Controllers depend on So while some might not follow this argument, imho its hard to argue that this isnt a sensible feature to provide to those that want it. 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
