在 MVC 中，控制器是否属于应用程序，还是可以进入共享库？例如：
//this is a shared library
LibShared
//these are two apps
appA ->LibShared
appB ->LibShared
每个应用程序不应该实现自己的 MVC 并使用任何共享库作为应用程序逻辑模型的一部分或只是另一个库引用（实用程序）？
另外，有没有 MVC 控制器卡在共享库中的情况？我认为控制器需要位于特定应用程序中的特定视图。意思是，控制器必须进入那个应用程序？
或者控制器可以是通用的（即共享库）？这是否意味着它们不再是控制器？
【问题讨论】：
标签： model-view-controller design-patterns
我建议您仅将控制器分离到它们自己的模块/包/库（此处称为模块）中，如果您有需要（即立即重用）。如果目前不存在这样的要求，那么我会将决定推迟到何时需要，在您的情况下听起来您将不必要地过度设计。理论上应该可以在没有太多障碍的情况下稍后重构为单独的模块，但是要注意耦合，分离到不同的模块不会减少耦合，请仔细查看您的依赖关系，控制器在多大程度上面向一种风格观点。
【讨论】：
对您的申请问题的回答是
是的，您可以将控制器移至单独的库，而无需更改单行代码。
【讨论】：
我想任何代码都可以去任何地方，是什么驱使我们将某些东西放入共享库或将其保留在应用程序中？
我会考虑两件事：
1)。变化率是多少？当我们整体改变应用程序时，这可能会改变。 2）。还有什么需要使用的吗？如果是这样，当我发布新版本时，其他客户端会立即
通常，控制器会与应用程序密切相关，因此对任何其他应用程序都没有太大兴趣，并且它可能是应用程序随应用程序变化而变化的基础。因此，与应用打包是有意义的。
现在如果控制器更通用，也许配置驱动然后共享库是有意义的。
【讨论】：
控制器不一定需要在同一个操作系统中。你可以在 Windows 中拥有一个视图，在 Unix 中拥有一个控制器，在 Sparc 中拥有你的模型。请记住，MVC 只是一种模式，一种您可以做一些更健壮且更容易修改的事情的方式。
您的控制器可以是共享库。你的控制器应该知道你的观点吗？不必要。这取决于您如何处理模块之间的通信。在一个好的 MVC 实现中，模块只是简单地交换消息或事件。因此，View 向 Controller 发送事件，Controller 决定做什么并返回消息。控制器的响应可能类似于“显示窗口 X”。请注意，“Window X”可以由 View 模块解释，如果 View 是 Web 模块，则 View 只需放置正确的 aspx 页面。如果您有另一个视图恰好是 Web 应用程序，则会呈现 Form X。
【讨论】：
至少在CakePHP 和 Mike McShaffry 在他的 Game Coding Complete 书中解释的架构中，控制器确实属于应用程序。
但是，在这两种情况下，架构都是这样的，即应用程序从框架中继承了模型、视图和控制器的基本功能。
例如：
// "super" controller of all applications using this framework
class Controller
// uses basic libraries that allows the inheriting applications to work minimally
class AppController extends Controller
// mainly uses the parent class's methods but can also substitute to using
// additional libraries
这里的框架是指封装库使用的系统。在 CakePHP 中，这种封装又是通过在相应的模型、视图和控制器中使用库来完成的。因此，这些组件都不能脱离库。
然而，在 Mike McShaffry 的架构中，只有控制器和视图使用库。因此模型是未耦合的，因此对于不同的应用程序具有高度的可移植性。
【讨论】：