Is it bad to inject controller class into a controller class?

Question

By trying to follow single responsibility principle, I decided that rendering form view I could move to another class. Also to render form I already am planning to use 5 dependencies. So the main controller which injects form will have less dependencies which is good.

I never injected controller classes into a controller class. What I usually do is I create the library. I have libraries folder made as sibling to controllers folder.

But now thinking - maybe better idea would be to have another controller injected into a controller?

Tried to search for this, but did not find any examples. But at the same time tried creating controller with just constructor function and echo a string. Then inject this controller into another. And string gets displayed.

So this means it is possible to inject controller into controller. So is it good? Or maybe this would be a must?

By default laravel do not even have libraries folder which is interesting, maybe creators assumes that it is not needed.

Antonio Carlos Ribeiro · Accepted Answer · 2014-10-10T14:17:06.787

Yes it's bad. Controllers not only must have one single responsibility, but they are also a different kind of class that should have only one job: A controller is a proxy between the HTTP request and your application (models, repositories, views). So basically it should receive an HTTP request, get some data from your models and pass it away to a view.

Everything else should be done by your support classes (models, repositories, helpers, composers, etc.).

If you are in need to call a second controller class, it's probably because you need methods on that controller that should not be in that controller, because your controllers are doing more than what their job is.

This is one of my controllers:

class Connect extends BaseController {

    public function index()
    {
        $connections = $this->execute(GetConnectionsCommand::class);

        return View::make('connections.index')->with('connections', $connections);
    }

}

There's a lot happening behind the scenes in that GetConnectionsCommand to get the information to show all connections, and my controller should not know any about it all.

There are some subviews on that ´connections.index´ view, but calling subviews are a view responsibility, my controller doesn't have to know that a particular view needs subviews to be rendered. I can have a master view and some @ifs inside it to render them all properly.

A controller returns data (a rendered view, rendered by another class) back to the response object (behind scenes in Laravel), which is the guy responsible for effectively rendering the data which will be passed back to your browser. So a controller is right in the middle of something, doing very little orquestration, because, the more it knows about your business logic, the more you'll feel it needs to ´talk´ to another controller. You can think of it as MVP if you like, but this is pure MVP using the Single Responsibility Principle as it should be. But in this case the Controller is not decoupled from the view, because there is no Interface between them, so it's not really MVP.

Interesting about views - you say controller does not have to know about subviews. I am doing the other way around - render all subviews in controller to variables, then pass those variables to parent views, so the parrent view can just use it like this: {{ $subview }}. But thats another topic I guess. — Dariux, Oct 10 '14 at 13:42
Isn't this more of an MVP framework since your "controller" returns something from a View — andyroo, Oct 10 '14 at 13:44
Sorry, was a question directed to @AntonioCarlosRibeiro 's example code — andyroo, Oct 10 '14 at 13:46

Is it bad to inject controller class into a controller class?

1 Answers1