在Robotlegs域逻辑是否需要位于命令（控制器）或模型中？RobotLegs域逻辑 - 在何处放置它
例如： 可以说我正在构建“Tic Tac Toe”游戏。我有： GameMadiatore，CellSelectedCommand，BoardModel。
用户点击单元格后，“GameMadiatore”触发一个启动“CellSelectedCommand”的事件。 “找到3行”赢得逻辑需要在“BoardModel”或“CellSelectedCommand”或其他命令？
我会建议你创建原子命令。
这意味着一个命令只应该做1件事和1件事。这允许您轻松地重新连接应用程序逻辑，而不会在以后重构太多。
在上面描述的情况下，您的想法是正确的，另一个命令可以做得很好。 例如：
约MVCS一些较原则：
干杯
正如@DennisJaamann说 - 一个命令只能做一两件事。但是，它应该包含实际的域逻辑，而不是有史以来的。它既不在模型中，也不在视图类中。如果你把你的游戏逻辑放到框架特定的类中，你将永远把你的游戏绑定到这个特定的框架（即使它是一个好的框架）。但是，TicTacToe的游戏规则应该始终保持不变，无论它们是否与RobotLegs，PureMVC或其他任何技术选择一起使用。例如，如果在几个月内，您决定为一些新颖的移动设备创建游戏版本，并且您想使用供应商特定的MVC框架和组件，否则您将不得不从头开始再做一切。另外，将游戏逻辑分散到几个命令类中会使得跟踪，阅读和理解代码变得更加困难 - 这使得调试变得非常痛苦。
As Uncle Bob Martin would put it：该框架是递送机制。没有更多，不少。它应该用来传递信息，即将其呈现给用户，并处理用户交互事件。但是实际的领域逻辑应该在框架不可知的用例类中，它们具有相反的依赖关系，因此完全与传递机制分离。所以，我会创建一个游戏界面，也许只是叫它ITicTacToe，并且在游戏类TicTacToe中实现它，它包含状态（即哪些单元格已被标记）和逻辑（即检查是否存在连续三次）执行和监控一轮TicTacToe。这些东西属于一起，因为它们用于相同的目的，并且它们具有相同的single reason to change：如果且仅当TicTacToe的规则发生变化！
使用TDD来实现游戏中的行为，并有每当比赛是赢了还是输了比赛类调度事件，而不是跟踪分数等等， - 这些都是应用逻辑周围比赛的一部分，但而不是游戏本身。
然后，您可以将游戏注入您的CellSelectedCommand，让该命令在游戏类中调用适当的方法，侦听本地游戏事件（如果有），然后通过中央调度程序调度应用程序范围内的事件。然后，您可以使用它们来触发单独的GameWonCommand和GameLostCommand类，以将分数添加到分数中并将其保留在ScoreModel中。模型应该只包含共享的状态，即多于一个任务所需的数据。我喜欢在一个大架子上考虑像抽屉和盒子这样的模型：你拿出一些你需要的数据来执行一个任务（即在开始游戏之前的一些用户信息），处理它（玩），然后把它存储起来（保存分数）。
概括起来讲，这里的经验法则：总是尽量保持你的核心应用程序逻辑不可知的框架和交付机制 - 他们应该是扩展，插件，如果你愿意，而不是系统的中心。
谢谢你的回答，我从没想过从这个角度来看。 –
说得好人！ –
我同意你为Mediator，Command和Model类型所陈述的原则，但是核心领域逻辑不应该包含在其中。看到我的答案。 – weltraumpirat