在像Rails这样的MVC框架中，总体共识就是将业务逻辑放入模型中。然而，当谈到像“解决用户解决的所有问题”这样的逻辑时，我不确定哪个模型类应该放置逻辑，因为它需要首先查找用户提交的所有解决方案，并收集问题每个解决方案的id，那么问题id可以得到所有需要的问题。何处放置逻辑处理多个模型
把它放在用户模型中会感觉更优雅，所以我们可以调用类似user.getAllProblemsSolved()的东西。但是，我们需要从用户实例中获取所有用户标识。在没有用户实例可用的地方，我们必须创建一个用于调用其getAllProblemsSolved方法的地方。
更重要的是，由于该逻辑主要处理问题和解决方案模型，因此它会将特征嫉妒置入用户模型中。为了避免Feature Envy，放入问题或解决方案感觉同样很好。直觉上，我会把它写成问题，如Problem.getAllProblemsSolvedBy(userId)，但我没有很好的理由。
那么我应该把这个逻辑放在哪里？
我可以看到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类是Solution类。分离代码以从代码中获取问题ID以获得问题听起来像是一个更好的内聚的好主意。唯一的问题是，现在控制器需要对模型进行两次调用而不是一次。 –
我已经更新了我的答案和详细的解释。 – mpcabd
我试图把你的问题分成几段;巨大的文字墙有点面对。 – Marty
您的问题源于误解。是的，模型应该包含业务逻辑。 **但“模型”不是类/对象。**相反，模型是一个应用程序层。你所说的“模型”实际上是滥用[activerecord]（http://martinfowler.com/eaaCatalog/activeRecord.html）模式的实例。请停止看Rails作为“正确实现的MVC”的例子，因为它不是。 –