根据定义，视图应该是无逻辑的。当用户与视图交互时，它会通知其控制器。当应用程序中的状态发生变化时，控制器会通知视图。但是当我重新渲染部分或全部视图时，我对视图与其控制器之间的通信性质感到困惑。
让我假装我正在制作一个双人纸牌游戏。视图负责显示牌组，弃牌堆，玩家手中的牌以及任何其他UI组件。当玩家玩牌时，视图需要反映这一变化，并且控制器的工作是通知视图这样做。以下哪个选项是处理此事件的最佳方式？
控制器只是简单地重新绘制视图。通过控制器，视图可以访问游戏状态的所有参数。它使用这些参数来重新绘制所有内容，包括牌组，玩家的双手等等。
控制器告诉视图玩家玩牌。该视图知道当玩家玩牌时，只需要重新绘制该玩家的牌。与选项1一样，视图使用游戏状态的参数来确定如何重新绘制玩家的手。
（类似但不同于2）控制器告诉视图重新绘制该玩家的手并将其传递给所需的所有参数。该视图无法访问游戏参数。
我缺少任何其他方法吗？
选项1似乎是最简单的两次写入，因为视图是无状态的 - 它只是每次都重新绘制所有内容。但出于同样的原因，这是非常浪费的。当一个玩家只玩一张牌时，我们不需要吸引玩家的双手。做动画之类的事情也很困难，因为每次我们重新绘制时，我们都会扔掉旧画布并用新的视图组件构建一个新的画布。
另一方面，选项3在从视图中删除逻辑方面似乎是最好的，但它带来了一些问题。首先，我发现编写起来比较困难，因为必须将所有正确的消息发送到视图中。如果遗漏任何内容，视图将无法正确反映应用程序的状态。其次，当用户正在恢复正在进行的已保存游戏时，似乎仍然需要完全重新绘制。
在选项1和2中，视图“提取”有关游戏状态的数据，而这些数据在选项3中被“推送”到它。如果视图能够请求这样的信息，或者这是否意味着也存在在视图中有多少逻辑？
提前感谢您对此主题的任何启发！
答案 0 :(得分：1)
MVC不适合所有应用程序。它还取决于可用的框架类型。
通过不考虑平台/框架，我会说HMVC（分层模型 - 视图 - 控制器）或PAC（演示 - 抽象 - 控制）更适合您，因为页面可以分成几个部分（三个视图：手和甲板）。
当谈到本机应用程序（GUI）时，似乎MVP优于MVC。
Martin Fowler在这里有一篇关于不同GUI模式的好文章：http://www.martinfowler.com/eaaDev/uiArchs.html