另一篇关于MVC责任的帖子，谁知道呢？

Question

想想纸牌游戏..。

电脑用卡片攻击人类。作为回应，玩家移动视图上的卡片来击败它。

在这种情况下，请确认：

(1)视图可以知道，屏幕上的“着陆区域”在哪里，无需询问控制器

(2)视图可以知道屏幕上的“防御”卡在哪里，而无需询问它的控制器

如果视图知道攻击者和维护者都是谁，那么(3)可以确定攻击者是否可以击败防御者吗？

如果这是不确定的，那么(4)是否可以对视图进行分类，而不是它的控制器(想想Utils类)，还是应该始终是控制器呢？

(5)会更好地将委托方法发送到控制器，指示“攻击者卡落在防御卡上”并期望布尔值攻击是否会成功？

Answer 1

视图是一个被动的输入/输出设备。它不应该知道任何游戏规则，比如攻击者是否能击败防守者。即使是控制器也不应该知道游戏规则，模型总是会决定这一点。

视图应该能够表示和处理所有可能的输入和输出状态，并将输入中继到控制器。控制器将输入信息传递给模型，并根据新的模型状态更新视图。在您的情况下，视图检测到卡A落在卡B上，并将信息传递给控制器。控制器将信息传递给模型，模型转换为新的游戏状态，控制器将视图更新为新状态。有时，视图可以通过直接观察模型来自动更新，这取决于情况。

考虑MVC分离规则的一个好方法是想象将游戏移植到不同的界面(GUI/CLI)或不同的外观。如果您发现您需要重做代码的很大一部分来支持不同的接口，那么除了界面特定的东西之外，您还必须接触一些东西，这意味着设计不是最优的。

设计直觉的另一个好来源是测试和模拟。如果想要运行一些自动测试或游戏模拟，您将被迫将游戏代码与模型内部的输入和输出分开。当逻辑分散在整个MVC上时，测试和模拟游戏就会伤害到您，并提醒您某些事情是错误的。