ruby-on-rails - Controller A 调用模型 B : Code smell?

Question

我有一个 toys Controller ，用户可以用它来领取要玩的玩具。现在，claim 方法在 Controller 级别实现(因为这 answer 建议我这样做)。

但是，现在声明逻辑变得有点臃肿，实际上不应该存在:如果一个 child 已经拥有 3 个玩具，则不能声明一个玩具，一个 child 不能声明另一个 child 声明的玩具，等等。该逻辑(在我看来)的明智点是在 child 模型中，因为我正在描述 child 的行为(他们可以做什么，不可以做什么)。

也就是说，如果我这样做，toys#claim Controller 操作将调用 child 模型中的方法。这是代码异味/不良做法吗？

(我猜有人会建议我为此使用服务对象。如果你这样做，能否请你指出一个简单的教程？最近关于这个的 RailsCast 对我来说有点太复杂了。)

提前致谢!

Answer 1

一般来说(在 Rails 之外)，它根本不是气味。事实上，我认为“模型”和“ Controller ”之间的纯 1:1 映射是一种味道。

注意:我不是 ROR 开发人员。我没有 ROR 方面的经验，也不知道它是如何实现的。但是，我确实非常了解设计模式，并且了解应用程序架构。话虽如此:

与其担心 1:1 映射，不如退一步思考应用程序的结构。

Controller 应该做什么？好吧，一般来说，它应该将用户操作路由到应用程序。这只是一个管道步骤。

那么模型(层)应该做什么？通常，模型是包含应用程序中所有业务逻辑的层。它将处理数据库交互、访问控制、业务操作等。因此，模型实际上是您应用程序的绝大部分。

另一方面， View 是您的表示层。它应该处理所有渲染，从模型层提取数据。

基于这种理解，您的模型、 View 和 Controller 应该能够彼此独立变化。总的来说，我希望看到 Controller 和 View 之间相当 1:1 的关系。我的意思是，每个存在的 Controller ，我都希望看到一个 View 。但是在没有用户交互的情况下可以存在 View 。在这些情况下，您可能需要一个 Controller (以呈现 View )，或者根据您的架构，您可能不需要一个。

但是“模型类”是模型层的一小部分(充当较低模型功能的代理或适配器)可能与 Controller 或 View 是 1:1 的，也可能不是。例如，您可能有一个从多个模型中提取数据的 View 。您可以拥有一个作用于多个模型的 Controller 。

现在您可以退一步说，如果 Controller 需要对多个模型进行操作，则创建一个抽象该操作的新模型。有时这是正确的做法。有时不是。这一切都归结为所涉及的特定操作和关系......

归根结底，这里没有“对”或“错”之分。在构建应用程序时，它确实涉及到您需要做出的设计决策。我不会太担心“气味”成分，只要它在您的应用程序中有意义...