MVC - 除了set / get成员之外，哪些方法应该在Model类中？

Question

在 Model 类memebers上进行操作的方法应该在 Model 或 Controller 中实现？这取决于这种操纵的“重”程度如何？

“操纵”我的意思是 - 获得一个类成员，根据他进行长时间计算，然后返回与该类相关的另一个值。

例如 - 拥有Board class来保存单元矩阵成员，现在我想实现一种方法，该方法根据特定的单元位置返回所有周围的单元格。谁负责实施上述？

如果此问题属于另一个Stack Exchange QA，欢迎发送帖子。

Answer 1

保持控制器的精简，不要让它们做太多，这与面向对象设计的SOLID中的单一责任原则相一致。如果你有胖控制器，它们就很难测试和维护。

至于模型，我曾经有过愚蠢的模型，之前除了映射到数据库表之外什么也没做，这是受到你在网上看到的大多数示例应用程序的启发，但现在我不这样做。

我（尝试）遵循域驱动设计的原则，其中模型（DDD术语中的实体）位于应用程序的中心，它们应该封装与实体相关的行为，它们是智能模型（所以是的，在这种情况下，与对象相关的逻辑将与它一起生活）。 DDD是一个更大的主题，它与MVC没有直接关系，但它背后的原理可以帮助您更好地设计您的应用程序，如果您使用谷歌DDD，有很多材料和示例应用程序可用。

此外，Ruby On Rails社区 - 似乎激发了大多数MVC框架 - 似乎也有关于Fat Models和Skinny Controllers的大肆宣传。

最重要的是，您可以将查看模型添加到我认为有帮助的混音中。在这种情况下，您可以使用ViewModel来表示模型的哑子集，仅用于生成视图，它可以让您的生活更轻松，并进一步将您的视图与模型分开，这样它们就不会影响您的设计不必要的决定。

Answer 2

你所谓的“模特”实际上是domain objects。 MVC中的实际模型只是一个层次，而不是具体的事情。

在您的特定示例中，Board应该有一个返回此列表的方法。我假设你实际上正在获取它，因为你需要与这些单元格进行进一步的交互。

这是模型层中services的用武之地。如果使用它们，它们是模型层的外部部分，包含应用程序逻辑 - 不同域对象之间的交互以及持久性（通常是data mappers或units of work）和域对象之间的交互。 / p>

  

假设您正在制作游戏，并且您和玩家执行AoE攻击。 Controller接受服务，负责此功能并发送命令：此玩家将AoE指向此方向，执行。

     

服务实例化Board并询问目标位置的周围单元格。然后它对它获得的集合中的每个单元格执行“损坏”。逻辑完成后，它会告诉工作单元实例提交Board上发生的所有更改。

Controller不关心服务的细节。它不应该收到任何反馈。当执行到达视图时，它从模型层请求最新更改并修改UI。作为附加的好处 - 服务可以让您阻止业务逻辑在表示层中泄漏（主要由视图和控制器组成）。

域对象应该只包含处理其状态的方法。

Answer 3

我认为这与MVC没什么关系，而且与常规软件工程有很多关系。

我个人会毫不犹豫地在模型中坚持琐碎的计算，但会非常警惕 fat <​​/ em>模型。

现在，MVC代表模型视图控制器的事实并不一定意味着所有应该是视图，模型或控制器。如果你认为有必要将责任转移到一个不具备M，V或C的独立类别，我不明白为什么你不应该这样做。

您实施它的方式取决于您。您可以将此单独的类用作“顶级”（缺少更好的术语）对象，或者将模型的方法委托给它，以隐藏您正在使用它的事实。我可能会选择后者。

但是，一切都值得商榷。每个人和他们的妹妹似乎对如何正确地进行MVC有不同的看法。

我，我只是认为它是一个指导方针。当然，这是一个好主意，因为它会让你更好地分离关注点，但最终 - 因为它总是发生 - 没有一种通用的方式来应用它，你不应该过度约束它，一切都必须是视图，模型或控制器。

Answer 4

根据最佳实践，我们应该使用仅具有访问权限的计算字段的属性。示例public double TotalCost {             得到             {                 返回this.Role.Cost * TotalHour;             }         }