1

按照定义,视图应该是无逻辑的。当用户与视图交互时,它会通知其控制器。当应用程序状态发生变化时,控制器通知视图。但是当我们重新渲染一些或全部视图的时候,我对视图与其控制器之间的通信的本质感到困惑。控制器和视图在MVC中应该如何分离?

让我们假装我正在做一个双人牌游戏。该视图负责显示甲板,丢弃堆,玩家手中的牌以及任何其他UI组件。当玩家玩牌时,该视图需要反映这种变化,而控制者的职责是通知视图这样做。以下哪个选项是处理此事件的最佳方法?

  1. 控制器告诉视图只是为了重新绘制。该视图通过控制器可以访问游戏状态的所有参数。它使用这些参数来重新绘制包括甲板,双方玩家的手等在内的所有东西。

  2. 控制器告诉视图玩家玩过一张牌。该视图知道当玩家玩牌时,只有该玩家的手需要重新绘制。与选项1一样,视图使用游戏状态的参数来确定如何重新绘制玩家的手。

  3. (类似但不同于2)控制器告诉视图重新绘制该玩家的手并将所需的所有参数传递给该玩家。该视图无法访问游戏参数。

  4. 我错过了其他方法吗?

选项1似乎是最简单的两种写法,因为视图是无状态的 - 它只是每次都重新绘制所有内容。但出于同样的原因,这是非常浪费的。当一个玩家玩牌时,我们不需要抽双手牌。做动画等事情也很困难,因为每次我们重新绘制时,我们都会扔掉旧的画布,并用全新的视图组件构建新的画布。

在频谱的另一端,选项3似乎是从视图中删除逻辑的最佳选择,但它带有一些问题。首先,我发现编写起来比较困难,因为必须将所有正确的消息发送到视图。如果有遗漏,视图将无法正确反映应用程序的状态。其次,当用户正在恢复正在进行的已保存的游戏时,似乎还需要全面重新抽奖。

在选项1和2中,视图“拉”有关游戏状态的数据,而这些数据在选项3中被“推送”给它。应该视图能够请求这样的信息,还是这意味着有视图中的逻辑太多了?

在此先感谢您提供有关此主题的任何信息!

回答

1

MVC不是最适合所有应用程序的。这也取决于可用的框架类型。

通过不考虑平台/框架我会说HMVC(分层模型 - 视图 - 控制器)或PAC(演示 - 抽象 - 控制)更适合你,因为页面可以被分割成几个部分(三个视图:手牌&甲板)。

当谈到本地应用程序(GUI)时,MVP似乎比MVC更受欢迎。

Martin Fowler的大约有不同的GUI模式口碑不错的文章:http://www.martinfowler.com/eaaDev/uiArchs.html

相关问题