Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
keymaster opened this issue Jun 27, 2011 · 7 comments
Closed

Comments

@keymaster
Copy link

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
Copy link
Contributor

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

@fabpot
Copy link
Member

fabpot commented Jun 27, 2011

@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.

@fabpot fabpot closed this as completed Jun 27, 2011
@mahono
Copy link

mahono commented Jun 27, 2011

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
Copy link
Member

fabpot commented Jun 27, 2011

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
Copy link
Contributor

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
Copy link

till commented Jun 29, 2011

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

@lsmith77
Copy link
Contributor

lsmith77 commented Jul 1, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants