Yes, I agree with Lukas. Commands defined as services introduce a lot of benefits. My favorite one is that it makes commands unit-testable.
How would you imagine having multiple DICs or even Kernels? A similar idea would be to just use a different kernel for console applications. That way, command services could be registered only if the kernel is a "ConsoleKernel". Having commands defined in another namespace just to circumvent the convention looks kind of ugly to me. Regards, Paul On Dec 10, 2012, at 9:01 AM, Lukas Kahwe Smith <m...@pooteeweet.org> wrote: > > 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 -- 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
