在哪里放置处理多个模型的逻辑答案

【问题标题】：Where to put logic dealing with more than one models在哪里放置处理多个模型的逻辑
【发布时间】：2014-04-22 05:45:14
【问题描述】：

在像 Rails 这样的 MVC 框架中，总体共识是将业务逻辑放入模型中。但是，当涉及到“获取用户解决的所有问题”之类的逻辑时，我不确定应该将逻辑放在哪个模型类中，因为它需要首先查找用户提交的所有解决方案，并收集问题每个解决方案的 id，然后是问题的 id，以获得所有需要的问题。

把它放在 User 模型中感觉更优雅，所以我们可以调用类似 user.getAllProblemsSolved() 的东西。但是，我们从用户实例中需要的只是用户 ID。在没有现成可用的用户实例的地方，我们必须创建一个来调用它的getAllProblemsSolved 方法。

而且，由于逻辑主要处理问题和解决方案模型，因此将其放在用户模型中会产生 Feature Envy 的味道。为了避免功能嫉妒，放入问题或解决方案感觉同样好。直觉上，我会把它放在问题中，就像Problem.getAllProblemsSolvedBy(userId)，但我没有很好的理由。

那么我应该把这个逻辑放在哪里呢？

【问题讨论】：

我试图把你的问题分成几段；巨大的文字墙有点令人生畏。
您的问题源于误解。是的，模型应该包含业务逻辑。 但是“模型”不是一个类/对象。相反，模型是一个应用层。您所说的“模型”实际上是滥用activerecord 模式的实例。请停止将 Rails 视为“正确实现的 MVC”的示例，因为它不是。

标签： model-view-controller business-logic

【解决方案1】：

我可以看到Problem和User之间的关系是m2m关系，所以如果你想按规矩把业务逻辑放到模型类里，可以把getAllProblemsSolvedBy放到模型类里那代表 m2m 关系，但使用该逻辑 getAllProblemsSolvedBy 将返回问题 ID，然后您必须从 Problem 模型类中获取问题。

我会将它放在 Problem 模型类中，因为该方法将返回 Problem 类的实例。

更新 2014 年 4 月 23 日 07:00 UTC

另请注意，在您的情况下，m2m 类 Solution 取决于 User 和 Problem 这两个模型的存在，因此您可以从该模型中查询这两个模型，因此如果我有我的代码中的 m2m 模型我通常让它负责查询 m2m 关系的两端。

例如，在您的情况下，getAllProblemsSolvedBy 可以在Solution 模型类中实现，它可以返回Problem 实例的列表，并且可以传递User 的实例。

【讨论】：

m2m 类是解决方案类。将代码从代码中分离出来以获取问题 id 以获取问题听起来是一个更好的凝聚力的好主意。唯一需要担心的是，现在控制器需要对模型进行两次调用而不是一次。