在Robotlegs中，域逻辑是否需要位于命令（控制器）或模型中？
实施例： 让我说我正在构建一个“Tic Tac Toe”游戏。 我有： GameMadiatore，CellSelectedCommand，BoardModel。
用户点击单元格后，“GameMadiatore”会触发一个启动“CellSelectedCommand”的事件。 “查找3行”获胜逻辑是否需要在“BoardModel”或“CellSelectedCommand”或其他命令中？
答案 0 :(得分：3)
正如@DennisJaamann所说 - 一个命令应该只做一件事。但是，它不应该永远包含实际的域逻辑。既不应该在模型中，也不应该在View类中。
原因如下：如果您将游戏逻辑放入特定于框架的类中，您将永远将游戏与这个特定的框架联系起来（即使它确实是一个很好的框架）。然而，TicTacToe的游戏规则应始终保持不变，无论它们是否与RobotLegs，PureMVC或您制作的任何其他技术选择一起使用。例如，如果在几个月内，您决定为某些花哨的新移动设备创建游戏版本，并且您希望使用特定于供应商的MVC框架和组件，那么您将不得不从头开始重新执行所有操作。此外，将游戏逻辑扩展到几个命令类使得跟踪，阅读和理解代码变得更加困难 - 这使调试成为一种真正的痛苦。
As Uncle Bob Martin would put it：框架是交付机制。不多也不少。它应该用于传递信息，即将信息呈现给用户，并处理用户交互事件。但实际的域逻辑应该在框架无关的用例类中具有反向依赖性，因此完全与传递机制分离。
所以，我会创建一个游戏界面，可能只是称之为ITicTacToe，并在游戏类TicTacToe中实现它，它包含两个状态（即哪些单元格已被标记）和逻辑（即检查是否连续三个）来执行和监控单轮TicTacToe。这些东西属于一起，因为它们用于相同的目的，并且它们具有相同的single reason to change：当且仅当TicTacToe的规则发生变化时！
使用TDD来实现游戏的行为，并在游戏获胜或失败时让游戏类发送事件，而不是跟踪得分等等 - 这些是应用程序逻辑的一部分 游戏，但不是游戏本身。
然后你可以将游戏注入你的CellSelectedCommand，让该命令调用游戏类中的相应方法，听取本地游戏事件（如果有的话），然后通过中央调度员发送应用程序范围内的事件。然后，您可以使用这些来触发单独的GameWonCommand和GameLostCommand类，以便为分数添加点并将其保留在ScoreModel中。模型应仅包含共享状态，即多个任务所需的数据。我喜欢在大货架上考虑抽屉和盒子等模型：你拿出执行任务所需的一些数据（即在开始游戏之前的一些用户信息），处理它（游戏），然后将其存储起来（保存分数）。
总结一下，这是一条经验法则：始终尝试让您的核心应用程序逻辑与框架和交付机制保持一致 - 它们应该是扩展，插件，如果您愿意，而不是系统的中心。
答案 1 :(得分：1)
我建议你创建原子命令。
这意味着命令应该只做1件事和1件事。这使您可以轻松地重新连接应用程序逻辑，而无需在以后重构太多。
在上面描述的情况下，你的想法是正确的另一个命令会做得很好。 例如：
关于MVCS的更多原则：
干杯