如果没有PHP框架，您将如何在MVC模式中编写控制器？
这是我的控制器的最简单版本
//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!";
}
}
正如您所看到的，只有模型作为其依赖项传递到我的控制器中。
这就是我如何理解MVC模式中的控制器，这可以在以下文章中参考，
https://r.je/views-are-not-templates.html
http://www.sitepoint.com/the-mvc-pattern-and-php-1/
PHP框架开发人员可能不同意这一点，因为大多数框架看起来都是MVC，但可能是Model 2。
在Model 2应用程序中，来自客户端浏览器的请求被传递至控制器。控制器执行任何必要的逻辑获得正确的显示内容。然后将内容放入请求（通常以JavaBean或POJO的形式），并决定它将把请求传递给哪个视图。然后，该视图将控制器传递的内容。
所以，如果我们要把这些框架放在一边，那么你该如何做你的控制器呢？
受您发布的一个链接的启发，我写了一系列关于编写MVC应用程序的文章。其中有一篇关于控制器的文章：管制员认真对待SRP
先读一读。
所以，如果我们要把这些框架放在一边，你该如何做控制器？
我的控制器没有对视图的引用。它们只更新代码示例中显示的模型，我认为这是正确的做法。控制器不应该包含绑定到视图的逻辑。相反，视图从模型中获取数据（请参阅视图从模型获取自己的数据，我还在其中解释了这种设计的优势）
控制器可以消耗任意多的依赖项（它们可能需要的不仅仅是注入的模型），但如果严格遵循SRP，控制器就不需要太多依赖项。
在大多数流行的框架中，您可以看到一个控制器，它具有用于视图渲染的一系列操作和绑定逻辑；相反，我将所有这些操作分离到单独的控制器中，这样控制器和视图之间就有了1:1的关系。这使我可以在不将逻辑绑定到视图的情况下拥有控制器（请参阅上面的链接，了解如何做到这一点的详细解释）。我的控制器也以这种方式更密切地遵循SRP。
当我在上面说控制器更新模型时，要注意MVC模型不仅仅是域模型。除了域模型之外，视图模型还存储视图渲染所需的状态，例如：允许更新实体的视图（比如用户）需要知道需要更新哪个用户（再次阅读文章以获得更详细的解释）。因此，在大多数情况下，我的控制器至少有两个依赖项，
- 允许我更新数据源的域模型（最常见的是ORM实例）
- 视图模型允许我更新视图呈现所需的应用程序状态（如要更新的用户、搜索过滤器等）
在这个问题之前，我没有见过Model 2，但据我所知，它只是一种特定于Java的MVC方法，并不是一种单独的设计模式。
你还没有真正解释为什么你认为你提到的PHP框架没有遵循MVC，至少在ZF中，通过传递依赖关系是很常见的做法。一个控制器的构造函数，就像您在自己的框架中的示例一样。
设计图案很容易落入兔子洞，实际上很大程度上取决于解读。仅仅因为一个模式的实现与另一个模式不同，并不一定意味着另一个实现是错误的。