如何在没有PHP框架的情况下以MVC模式编写控制器？

Question

How will you write your controller in MVC pattern without PHP frameworks?

This is the simplest version of my controller,

//Controller
class Controller
{
    private $model;

    public function __construct($model){
        $this->model = $model;
    }

    public function clicked() {
        $this->model->string = "Updated Data, thanks to MVC and PHP!";
    }
}

As you can see that only model is passed into my controller as its dependency.

This is how I understand the controller in MVC pattern which can be referenced in these following articles,

https://r.je/views-are-not-templates.html

http://www.sitepoint.com/the-mvc-pattern-and-php-1/

PHP framework developers probably disagree with this, because as most frameworks seem to be MVC, but probably are Model 2.

In a Model 2 application, requests from the client browser are passed to the controller. The controller performs any logic necessary to obtain the correct content for display. It then places the content in the request (commonly in the form of a JavaBean or POJO) and decides which view it will pass the request to. The view then renders the content passed by the controller.

So if we are going to put these frameworks aside, how do you do your controller then?

Answer 1

I've written a series of articles for writing MVC applications, inspired by one of the links you posted. Among those there is an article about Controllers: Controllers are taking SRP seriously
Have a read at it first.

So if we are going to put these frameworks aside, how do you do your controller then?

My controllers don't have a reference to the view. They only update the model as shown in your code sample, and I think that's the right way to do. Controllers shouldn't contain binding logic to the view. Instead, the view gets its data from the model (see The View gets its own data from the Model where I also explain the advantages of such a design).
Controllers can consume as many dependencies as they want (they might need more than just the model injected), but if you follow SRP closely, controllers won't need a lot of dependencies.

In most popular frameworks, you see a controller with a bunch of actions and binding logic for view rendering; I instead separate all these actions into separate controllers so that I have a 1:1 relationship between controller and view. This allows me to have controllers without binding logic to the view (see link above for detailed explanation on how I do that). My Controllers also follow SRP more closely this way.

When I said above, that the controller updates the model, beware that MVC Models are not just Domain Models. In addition to Domain Models, View Models store the state that the view needs for rendering, e.g.: the view allowing to update an entity like let's say a User, needs to know which user needs to be updated (again, read articles for more detailed explanations). My Controllers have thus in most cases at least two dependencies,

1. a domain model (most frequently an ORM instance) allowing me to update the datasource
2. a view model allowing me to update the application state (like which user is to be updated, search filters, ...) necessary for view rendering