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