通过尝试遵循单一责任原则，我决定可以将呈现表单视图转移到另一个类。此外，为了呈现表单，我已经计划使用5个依赖项。因此，注入表单的主控制器将具有较少的依赖性，这是好的。
我从未将控制器类注入控制器类。我通常做的是创建库。我有一个库文件夹作为控制器的兄弟文件夹。
但现在想——也许更好的想法是在控制器中注入另一个控制器？
试图对此进行搜索，但没有找到任何示例。但同时尝试只使用构造函数和回显字符串来创建控制器。然后将此控制器注入另一个控制器。并显示字符串。
所以这意味着可以将控制器注入控制器。那么它好吗？或者这可能是必须的？
默认情况下，laravel甚至没有有趣的库文件夹，也许创建者认为不需要它。
是的，这很糟糕。控制器不仅必须有一个单一的职责，而且它们也是一种不同的类，应该只有一个作业：控制器是HTTP请求和应用程序（模型、存储库、视图）之间的代理。因此，基本上它应该接收一个HTTP请求，从模型中获取一些数据，并将其传递给视图。
其他一切都应该由您的支持类（模型、存储库、助手、作曲家等）来完成
如果你需要调用第二个控制器类，那可能是因为你需要该控制器上不应该在该控制器中的方法，因为你的控制器所做的比他们的工作更多
这是我的一个控制器：
class Connect extends BaseController {
public function index()
{
$connections = $this->execute(GetConnectionsCommand::class);
return View::make('connections.index')->with('connections', $connections);
}
}
在GetConnectionsCommand中，为了获得显示所有连接的信息，在幕后发生了很多事情，而我的控制器应该对此一无所知。
"connections.index"视图上有一些子视图，但调用子视图是视图的责任，我的控制器不必知道特定视图需要渲染子视图。我可以有一个master视图和里面的一些@if来正确地渲染它们。
控制器将数据（渲染视图，由另一个类渲染）返回到响应对象（Laravel中的幕后），该对象负责有效地渲染将传递回浏览器的数据。因此，一个控制器就在某件事的中间，做很少或请求，因为它对您的业务逻辑了解得越多，您就越觉得它需要与另一个控制器"对话"。如果你愿意，你可以把它看作MVP，但这是使用单一责任原则的纯粹MVP。但在这种情况下，控制器与视图没有解耦，因为它们之间没有接口，所以它不是真正的MVP。