我正在使用Codeignitor 2.x，我最初使用控制器作为模块（虽然不完全是HMVC），因为我有一个可以调用其他低级控制器的顶级控制器。我的想法是，因为这些较低级别的控制器仍在与视图交互，所以它们应该是控制器而不是模型或驱动程序。
然而，我发现控制器的每个实例也会产生一个新的CI实例。所以我会为每个请求运行3或4个CI实例。开销很大，也导致了会话问题。
我已将这些较低级别的控制器作为驱动程序移入库中。他们现在在构造方法中捕获CI实例，并对其进行修改。这使得它非常好用，并且不需要HMVC扩展。这些驱动程序也不是外部可调用的，因此它允许我通过特定的入口点汇集所有请求。
我的问题是这是否在结构上是正确的。我一直认为驱动程序应该只修改通过方法调用提供的数据，但许多驱动程序将直接从GET和POST，虽然它们不会直接附加到View，但它们经常访问视图文件，并将处理后的视图传递给CI实例进行输出。
[编辑] 更多上下文： 我创建的其中一个驱动程序本质上是一个名为“Access”的用户登录驱动程序。它调用“用户”模型来创建/登录/注销方法。驱动程序使用POST数据检查用户模型，然后加载错误和所需的正确视图。这个想法，有2行，我可以在整个项目的任何控制器中包含这个驱动程序，因此代码冗余显着减少。同样，我知道驱动程序应该局限于它们的范围，但驱动程序不会修改其范围之外的任何内容，而只是返回它创建的视图。
是否还有另一种方法可以实现更直接的MVC？
答案 0 :(得分：0)
我不能说这是对还是错。但如果我是你，我就不会这样做。我可能会重构一些代码。我确保他们不会直接从$_GET或$_POST超全局抓取和操纵数据。而是将一些数据作为参数传递给函数调用。这样可以简化测试，因为您不必模拟GET或POST请求。虽然从技术上讲，你可以从代码手动设置超全局的值，但我不建议这样做。提供数据作为参数会好得多，特别是如果您想编写随后要执行的测试用例。此外，让库与范围之外的库进行交互可能会引入一些隐藏的问题。
在我看来，库就像模块一样，你可以拖放，然后毫不费力地使用它们。如果您的代码确实需要抓取或操纵$_GET或$_POST中的值，那么它们可能就是模型。此外，您可能想要考虑您的代码是否实际上是一个库。问问自己，这个代码在这个应用程序之外是否有用？或者它是高度依赖的，只对这个特定的应用程序有用吗？如果你对后者说“是”，那么它可能应该是模型而不是库。最后，您应该将视图留给控制器。只需从库/模型方法返回所需的数据，然后将其传递给控制器的视图。