Rails：每个模型都需要一个控制器吗？ [关闭]答案

【问题标题】：Rails: Do I need a controller for each model? [closed]Rails：每个模型都需要一个控制器吗？ [关闭]
【发布时间】：2013-09-26 22:30:49
【问题描述】：

我有一个包含 4 个模型的 Rails 应用程序。我只在一个控制器操作中访问这 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

【问题讨论】：

从这里很难说，我看不到你出轨会得到什么
将要关闭的问题标记为“主要基于意见”，因为这实际上取决于在这些操作中是否不仅包含此信息。

标签： ruby-on-rails ruby ruby-on-rails-3 rails-activerecord

【解决方案1】：

TL;DR

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

不，不一定。但是，每个 RESTful 资源都有一个控制器是一种约定，这是有原因的，在做一些完全不同的事情之前，您应该仔细分析为什么该约定不能满足您的需求。

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

您似乎将 RESTful 资源与 Rails 的 MVC 实现混为一谈。作为一般规则，您的控制器应包含与资源相关的操作。如果您的应用程序将“仪表板”视为一种资源，那么如果您正在对某种仪表板对象执行 RESTful 操作，那么单个 DashboardController 肯定是有意义的。

约定不是物理定律

Rails 使用大量约定来以 RESTful 方式映射资源，但有时这些约定与实际应用程序不匹配。在这种情况下，您可能会发现一个控制器可以处理您需要的所有操作，或者单个模型可能满足多个控制器的需求。

但是，在您构建所有 MVC 层之前，花一些时间考虑一下您是否在概念上为您的应用程序捕获了正确的资源模型通常很有用。您的资源真的是 Dashboard 对象吗？ Dashboard 对象真的需要 Dashboard#gs_data 方法来表示其行为，还是 GsData#index 在语义上更有意义？

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

【讨论】：

这应该是公认的答案。

【解决方案2】：

除非你有一个真的很好的理由，否则你应该坚持使用常规名称，如index、new、show 等。 dashboard 是什么？在我看来，它与index 完全一样。请记住，您可以通过操作路由表来使 index 操作的路径随心所欲地调用，但在内部它应该是一致的并遵循约定以确保它是可维护的。

请注意，您的控制器很少这么简单，除非在一开始。随着时间的推移，您将添加诸如分页、搜索、过滤、排序和一堆其他代码，这些代码会让您的全能控制器变得非常笨拙。

不用担心创建微型控制器。这是好事。在模型和控制器之间建立一对一的关联可以消除很多关于谁负责该特定模型的混淆。

【讨论】：

【解决方案3】：

这里简单说两点：

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

【讨论】：