Rails：每个模型都需要一个控制器吗？

Question

我有一个Rails应用程序，有4个模型。我只在每个控制器操作中访问这4个模型。我目前有4个不同的控制器来处理这些模型。我想知道将这4个操作都放入一个控制器中是否是不好的做法。 当前设置：

class GmDataController < ApplicationController
    def dashboard
      @data = GmData.all
    end
end

class GmRetentionController < ApplicationController
    def dashboard
      @data = GmRetention.all
    end
end

class GsDataController < ApplicationController
    def dashboard
      @data = GsData.all
    end
end

class GsRetentionController < ApplicationController
    def dashboard
      @data = GsRetention.all
    end
end

建议设置：

class DashboardController < ApplicationController
    def gm_data_dashboard
      @data = GmData.all
    end

    def gm_retention_dashboard
      @data = GmRetention.all
    end

    def gs_data_dashboard
      @data = GsData.all
    end

    def gs_retention_dashboard
      @data = GsRetention.all
    end
end

- user2158382

---

很难从这里说，我看不到你偏离轨道的原因。 - Tony Hopkinson

将该问题标记为“主要基于观点”关闭，因为这实际上取决于那些操作中是否会有更多的信息。 - Ryan Bigg

Answer 1

简而言之

每个模型都需要一个控制器吗？

不一定需要。然而，每个RESTful资源都有一个控制器的惯例是有原因的，你应该仔细分析为什么这个惯例不能满足你的需求，然后再做完全不同的事情。

考虑“资源”，而不是控制器

你似乎把RESTful资源和Rails实现的MVC混淆了。通常情况下，你的控制器应该包含与资源相关的操作。如果你的应用程序将“仪表板”视为一种资源，则单个DashboardController可能是有意义的，如果你正在对某种类型的Dashboard对象执行RESTful操作。

惯例不是物理定律

Rails使用许多惯例以RESTful方式映射资源，但有时这些惯例不符合实际应用程序。在这种情况下，你可能会发现一个控制器可以处理所有你需要的操作，或者一个模型可以服务于多个控制器的需求。

然而，在混淆所有MVC层之前，花点时间思考你是否已经概念化了正确的资源模型对你的应用程序非常有用。你的资源是否真的是一个仪表板对象？仪表板对象是否真的需要一个Dashboard#gs_data方法来表示其行为，或者GsData#index在语义上更有意义？

最终，如果你不想以RESTful方式使用Rails，甚至不必这样做。然而，你真的应该有比你在上面的原始问题中提出的更好的理由（从面向对象分析的角度来看）。

- Todd A. Jacobs

---

这应该是被接受的答案。 - Patricio Sard

Answer 2

除非你有一个真正好的理由，否则你应该坚持使用传统的名称，如 index ， new ， show 等。什么是 dashboard ？对我来说它看起来完全像 index 。请记住，您可以通过操作路由表将指向 index 操作的路径命名为任何您想要的名称，但在内部，它应该是一致且遵循约定以确保可维护性。

说明一下，除了在最初阶段之外，您的控制器很少如此琐碎。随着时间的推移，您将添加诸如分页、搜索、过滤、排序和大量其他代码，这将使您的 omni-controller 变得非常笨拙。

不要担心创建小型控制器。这是件好事。模型和控制器之间的一对一关系消除了许多关于谁负责特定模型的混淆。

- tadman

Answer 3

这里只有两点：

1. 只有在相对应的模型上有请求操作时才需要控制器；
2. 当一个模型仅用于数据计算和基本业务逻辑实现时，不需要生成控制器。

- Max Wong