我有一个toys控制器，用户可以用它来认领玩具。现在，该claim方法在控制器级别实现（正如这个答案所建议的那样）。
但是，现在声称真正不应该存在的逻辑变得有点胖了：如果一个孩子已经拥有 3 个玩具，他们就不能声称一个玩具，一个孩子不能声称另一个孩子声称的玩具，等等. 该逻辑的合理点（在我看来）在child模型中，因为我正在描述孩子的行为（他们可能会做和可能不会做的事情）。
也就是说，如果我这样做，toys#claim控制器操作将调用child模型中的方法。这是代码异味/不好的做法吗？
（我猜有人会建议我为此使用服务对象。如果你这样做了，你能指出一个简单的教程吗？最近关于这个的 RailsCast 对我来说有点太复杂了。）
提前致谢！
一般来说（在 Rails 之外），它根本不是一种气味。事实上，我认为在“模型”和“控制器”之间进行纯粹的 1:1 映射是一种味道。
注意：我不是 ROR 开发人员。我在 ROR 或它如何实现事物方面没有经验。但是，我确实非常了解设计模式，并且了解应用程序架构。照这样说：
与其担心 1:1 映射，不如退一步考虑一下应用程序的结构。
控制器应该做什么？好吧，一般来说，它应该将用户操作路由到应用程序。这只是一个管道步骤。
那么模型（层）应该做什么？通常，模型是一个包含应用程序中所有业务逻辑的层。它将处理数据库交互、访问控制、业务操作等。因此，模型实际上是您应用程序的绝大多数。
另一方面，视图是您的表示层。它应该处理所有渲染，从模型层提取数据。
基于这种理解，您的模型、视图和控制器应该能够相互独立地变化。一般来说，我希望看到控制器和视图之间的关系相当 1:1。我的意思是每个存在的控制器，我都希望看到一个视图。但是可能存在没有用户交互的视图。在这些情况下，您可能需要一个控制器（来渲染视图），或者根据您的架构，您可能不需要一个。
但是“模型类”是模型层的一小部分（充当较低模型功能的代理或适配器）与控制器或视图可能是或可能不是 1:1。例如，您可能有一个从多个模型中提取数据的视图。您可以拥有一个作用于多个模型的控制器。
现在您可以退后一步说，如果控制器需要对多个模型进行操作，则创建一个抽象该操作的新模型。有时这是正确的做法。有时不是。这一切都归结为所涉及的具体操作和关系......
归根结底，这里没有“对”或“错”之分。在构建应用程序时，确实需要做出设计决策。我不会太担心“气味”组件，只要它在您的应用程序中有意义......