控制器和视图之间的耦合

Question

对我来说，良好的 MVC 实现的试金石是交换视图是否容易。由于懒惰，我一直做得很糟糕，但现在我想把它做好。这是 C++ 语言，但如果我相信这种炒作，它应该同样适用于非桌面应用程序。

下面是一个示例：应用程序控制器必须在后台检查某个 URL 是否存在。它可以连接到“URL available”事件（使用 Boost Signals），如下所示：

BackgroundUrlCheckerThread(Controller & controller)
{
   // ...
   signalUrlAvailable.connect(
      boost::bind(&Controller::urlAvailable,&controller,_1))
}

那么 Controller::urlAvailable 是什么样子的？

这是一种可能性：

void
Controller::urlAvailable(Url url)
{
    if(!view->askUser("URL available, wanna download it?"))
      return;
    else
      // Download the url in a new thread, repeat
}

对我来说，这似乎是视图和控制器的粗耦合。这种耦合使得在使用网络时无法实现视图（协程除外）。

另一种可能性：

void
Controller::urlAvailable(Url url)
{
   urlAvailableSignal(url); // Now, any view interested can do what it wants
}

我偏向后者，但看起来如果我这样做，将会有：

1. 400 亿个这样的信号。对于一个不平凡的应用程序来说，应用程序控制器可能会变得巨大
2. 给定视图意外忽略某些信号的可能性非常大（API 可以在链接时通知您，但信号/槽是运行时）

那么您建议删除什么耦合并降低复杂性？提前致谢。

Answer 1

对我来说，良好的 MVC 实现的试金石是交换视图是否容易。

我可能会因为这样说而招致批评，但我不同意这种说法。这在纸面上看起来不错，但现实世界的示例表明，良好的 UI 是响应式和交互式的，这通常需要将视图和控制器交织在一起。尝试编写一个完全通用的控制器来处理不可预见的理论视图会给控制器和视图增加大量的代码和复杂性。根据我的经验，互连的视图/控制器效果更好 - 我将其视为“M(VC)”。

我想说，良好的 MVC 实现的试金石是如何轻松地将另一个视图/控制器对“添加”到模型中。模型的更改是否从一个视图/控制器（例如桌面操作员）传播到另一视图/控制器（例如Web 远程用户）。该模型是否足够通用以支持不同的视图/控制器范例（例如桌面 GUI、命令行、计划/批量输入、基于 Web 的 UI、Web 服务等）？

这并不是说控制器代码不能共享（例如，从公共基础派生），但您必须在控制器应处理的内容（模型的外部操作）和应处理的内容之间找到正确的界限。被视为模型行为的一部分（模型的内部转换）。查看代码同上。

我想阅读““控制器”中的内容”下的一些答案“MVC” 也会对此有所帮助。

Answer 2

您可以使用“m”模型使它们解耦，并使用（在概念上）类似命令的模式和侦听器模式来降低复杂性。

所以你的控制器可能看起来像这样：

void
Controller::urlAvailable(Url url)
{
   Controller::fireSignal("urlAvailable", url, ... other possible parameter);
}
Controller::fireSignal(char* cmd, Url url, ... other possible parameters) {
   Model &M   = new Model();
   M->command = cmd;
   M->url     = url;
   M-> ... other possible
   for(int v = Controller::ViewCount; --v >= 0; )
      Controller::Views[v]->notice(M);
}

注意：我不是 C++ 程序员，所以请原谅我错误的语法。

MVC 的整体思想是使用 M(odel) 将 C(ontrol) 与 V(iew) 解耦。该示例极其简化。更实用的一种是对不同种类的相似信号使用不同的模型。

希望这有帮助。