Skip to content

Improved the advantages/drawbacks of "controllers as services" #7495

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

Merged
merged 1 commit into from
Jul 21, 2017

Conversation

javiereguiluz
Copy link
Member

This fixes #6749.

@javiereguiluz javiereguiluz changed the base branch from master to 2.7 February 14, 2017 16:24
@Jean85
Copy link
Contributor

Jean85 commented Feb 16, 2017

LGTM 👍
Status: reviewed

@@ -23,17 +23,19 @@ These are the main **advantages** of defining controllers as services:
service container configuration. This is useful when developing reusable bundles;
* Your controllers are more "sandboxed". By looking at the constructor arguments,
it's easy to see what types of things this controller may or may not do;
* If you're not passing some required dependencies or if you are injecting some
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is worth clarifying the semantic above, because technically this is not the constructor of a controller but of a class of controllers, in this way a Dunglas action is more a controller than the base controller class.

* Since dependencies must be injected manually, it's more obvious when your
controller is becoming too big (i.e. if you have many constructor arguments).

These are the main **drawbacks** of defining controllers as services:

* It takes more work to create the controllers because they don't have
automatic access to the services or to the base controller shortcuts;
* It takes more work to create the controllers and they become more verbose
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really agree, controller's method should be as thin as possible and just calling services to do things to end by returning a response (so I've been told :). If services are there no need for shortcuts anymore. In the end you're just calling explicitly some methods, some would say "without magic" :D.

Again the semantic does not look appropriate because from a DI point of view defining an object makes it a service, but orchestrate an action requires to call every needed services, hence the need to access them.

The way we always used in Symfony is by making the controller class container aware, but defining explicitly the needed dependencies is not that different since the controller class is just virtual, what's truly needed is a locator and to group actions by scopes.

The new locator feature is awesome for this, and Symfony is great for letting every ways of coding possible, because they are all powerful in their way, one just need to do and learn what he can and want to do with it.

Personally I don't prefer one way or another, as long that it makes sense to do what you got to do.

By letting everyone playing with it some ways may die naturally on the long run.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry but I don't understand your comment. Let me show you why I wrote that phrase.


For such a common thing as rendering a template, if you use the base controller, you do this:

return $this->render('homepage.html.twig');

Just 1 short and beautiful PHP line.

However, if you don't use that base controller, the equivalent code is this one:

        if (!$this->container->has('twig')) {
            throw new \LogicException('...');
        }
        
        $response = new Response();
        $response->setContent($this->container->get('twig')->render('homepage.html.twig'));

        return $response;

So, I think the previous phrase is correct: "It takes more work" ... and "they become more verbose".

Copy link
Contributor

@HeahDude HeahDude Feb 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if the Twig environment is a hard (or safe) dependency, it could just be:

return $this->twig->renderResponse('homepage.html.twig');

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the working example would be:

private $twig;

public function __construct(\Twig_Environment $twig)
{
    $this->twig = $twig;
}

return $this->twig->renderResponse('homepage.html.twig');

So, again, "it takes more work" and "they become more verbose" 😄

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The class is but not the controllers in it :p

@wouterj
Copy link
Member

wouterj commented Mar 5, 2017

👍

@xabbuh
Copy link
Member

xabbuh commented Jul 21, 2017

Thank you Javier.

@xabbuh xabbuh merged commit e8b9e62 into symfony:2.7 Jul 21, 2017
@xabbuh xabbuh added this to the 2.7 milestone Jul 21, 2017
xabbuh added a commit that referenced this pull request Jul 21, 2017
…ices" (javiereguiluz)

This PR was merged into the 2.7 branch.

Discussion
----------

Improved the advantages/drawbacks of "controllers as services"

This fixes #6749.

Commits
-------

e8b9e62 Improved the advantages/drawbacks of "controllers as services"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants