Mention best practice "controller as a service" in Controller chapter

[keymaster]

Controller as a service is continually touted as the best practice.

Yet none of the examples in the book use controllers as a service, nor does a recommendation to do that even appear in the book.

There is merely the following phrase in the controller chapter: "You can also define your Controllers as Services."

Perhaps it might be better to mention something to the effect:

"While we have shown you the easy and quick way of getting started with controllers, we recommend the best practice of creating controllers as a service for the following reasons, ... and here is the link to the cookbook article on how to do it."

[lsmith77]

While I do think its a best practice, I don't think that its universally agreed upon. Specifically from my understanding @fabpot disagrees.

[fabpot]

@lsmith77 is right. I strongly believe that this is NOT a best practice. I don't recommend it at all. That's why it's not in the book and explained in a cookbook entry.

[mahono]

It would be nice to understand why what is (not) best practice. @fabpot: could you give some more info why you think so (or is there more information about that somewhere else?) To me most important is to learn best practices how to make my bundles customizable.

[fabpot]

The DIC mostly helps manage "global" objects. Controllers are not global objects. Moreover, a controller should be as thin as possible. It's mainly the glue between your Model and the View/Templates. So, if you need to be able to customize then, it probably means that you need to refactor them and extract the business logic from them.

[lsmith77]

i guess i should do a blog post, but yes the key question is if controllers are reusable or not. if you assume they are not, then making them services has less merit. in FOSUserBundle we pushed as much code out of the controller as possible, but where still left with a bit of code. we also split the controllers into more specialized controllers. so at this point its now somewhat feasible to simply reimplement controllers. in general both steps are a good idea to do regardless of the topic of controllers as services or not.

@fabpot didnt mention this, but i also believe that controllers should be functionally tested and not unit tested. so this is again one less reason to use DI with controllers.

the big reason why i still insist on defining my controllers as services is exactly because they are the glue between all other services. as you split controllers and add more services etc it becomes very hard to keep an overview of what the different controller actually depend on. this is where using services are such a huge advantage, since you have the DIC to turn to if you want to figure out what impact a refactoring of a given service has.

furthermore i also think that especially as you strip controllers down to just being glue between services you increase the chances of them actually being reusable and therefore it again makes sense to be able to customize their behavior by simply modifying the services they use, rather than having to extend or reimplement them from scratch ..

anyway .. really i should blog about this :)

[till]

Adding Igor's gist: https://gist.github.com/1050974

[lsmith77]

FYI http://pooteeweet.org/blog/1947