2

在Robotlegs中，域逻辑是否需要在命令（控制器）或模型中？

示例：假设我正在构建一个“井字游戏”游戏。我有：GameMadiatore、CellSelectedCommand、BoardModel。

在用户单击一个单元格后，“GameMadiatore”会触发一个启动“CellSelectedCommand”的事件。“find 3 in row”获胜逻辑是否需要在“BoardModel”或“CellSelectedCommand”或其他命令中？

4

2 回答 2

3

正如@DennisJaamann 所说——一个命令应该只做一件事。但是，它不应该包含实际的域逻辑。它既不应该在模型中，也不应该在视图类中。

原因如下：如果您将游戏逻辑放入特定于框架的类中，您将永远将您的游戏与这个特定的框架联系起来（即使它确实是一个很好的框架）。然而，井字游戏的游戏规则应该始终保持不变，无论它们是与 RobotLegs、PureMVC 还是您选择的任何其他技术一起使用。例如，如果在几个月后，您决定为一些花哨的新移动设备创建一个游戏版本，并且您想使用供应商特定的 MVC 框架和组件，否则您将不得不从头开始做所有事情。此外，将游戏逻辑分布在多个命令类上会使得代码更难遵循、阅读和理解——这让调试变得非常痛苦。

正如 Bob Martin 叔叔所说： 框架是一种交付机制。不多也不少。它应该用于传递信息，即将信息呈现给用户，并处理用户交互事件。但是实际的领域逻辑应该在具有反向依赖关系的框架不可知用例类中，因此与交付机制完全解耦。

所以，我会创建一个游戏接口，也许只是调用它ITicTacToe，然后在一个游戏类中实现它TicTacToe，它包含状态（即哪些单元格已被标记）和逻辑（即检查是否连续三个）执行和监控单轮井字游戏。这些东西是在一起的，因为它们用于相同的目的，并且它们有相同的改变理由：当且仅当井字游戏的规则改变时！

使用 TDD 来实现游戏的行为，并让游戏类在游戏输赢时调度事件，而不是跟踪分数等 - 这些是围绕游戏的应用程序逻辑的一部分，而不是游戏本身。

然后，您可以将游戏注入您的CellSelectedCommand，让该命令调用游戏类上的适当方法，侦听本地游戏事件（如果有），然后通过中央调度程序调度应用程序范围的事件。然后，您可以使用这些来触发单独的GameWonCommand和GameLostCommand类以将分数添加到分数并将其保留在ScoreModel. 模型应该只包含共享状态，即多个任务需要的数据。我喜欢把模型想象成一个大架子上的抽屉和盒子：你取出一些执行任务所需的数据（即开始游戏之前的一些用户信息），处理它（玩），然后将其存储起来（保存分数）。

总结一下，这里有一条经验法则：始终尝试让您的核心应用程序逻辑与框架和交付机制无关——如果您愿意，它们应该是扩展、插件，而不是系统的中心。

于 2012-09-27T23:26:27.620 回答
1

我建议您创建原子命令。

这意味着一个命令应该只做一件事和一件事。这使您可以轻松地重新连接应用程序逻辑，而无需在以后进行太多重构。

在上述情况下，您的想法是正确的，另一个命令就可以了。例如：

  • 单元格选择命令
  • Check3InRow 命令
  • 开始新游戏命令
  • PlayerWinsCommand
  • ..

关于 MVCS 的更多原则：

  • 调解员：应该被视为邮递员。它将充当您的视图和应用程序之间的中间人。如果你愿意，可以称它为 ViewController，但这样更基本。
  • 命令：可以认为是控制器逻辑，所有的决策都可以在这里完成。从这里更新您的模型。
  • 模型：应该只反映应用程序状态。例如一个布尔值，指示游戏是否已赢。

干杯

于 2012-09-27T15:50:59.100 回答