1

根据定义,视图应该是无逻辑的。当用户与视图交互时,它会通知其控制器。当应用程序中的状态发生变化时,控制器会通知视图。但是当需要重新渲染部分或全部视图时,我对视图与其控制器之间的通信性质感到困惑。

让我们假设我正在制作一个两人纸牌游戏。该视图负责显示牌组、弃牌堆、玩家手中的牌以及任何其他 UI 组件。当玩家打牌时,视图需要反映这种变化,而通知视图这样做是控制器的工作。以下哪个选项是处理此事件的最佳方式?

  1. 控制器简单地告诉视图重新绘制。视图通过控制器可以访问游戏状态的所有参数。它使用这些参数重新绘制所有内容,包括牌组、玩家的手牌等。

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

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

  4. 我还缺少其他方法吗?

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

另一方面,选项 3 在从视图中删除逻辑方面似乎是最好的,但它带来了一些问题。首先,我发现编写起来更加困难,因为必须将所有正确的消息发送到视图。如果有任何遗漏,视图将无法正确反映应用程序的状态。其次,有时似乎仍然需要完全重新绘制,例如,当用户正在恢复正在进行的已保存游戏时。

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

提前感谢您对这个主题的任何启发!

4

1 回答 1

1

MVC 并非最适合所有应用程序。它还取决于可用的框架类型。

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

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

Martin Fowler 在这里有一篇关于不同 GUI 模式的好文章:http: //www.martinfowler.com/eaaDev/uiArchs.html

于 2012-04-25T07:15:04.080 回答