Question

我有一个包含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

Answer 1

TL; DR

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

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

想想“资源”，“非控制者”

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

约定不是物理定律

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

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

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

Answer 2

除非你有真正的充分理由，否则你应该坚持使用index，new，show之类的传统名称，等等。什么是dashboard？它看起来与我index完全一样。请记住，您可以通过操作路由表来调用index操作的路径，但在内部它应该是一致的，并遵循惯例以确保它是可维护的。

作为一个注释，除了一开始，你的控制器很少是微不足道的。随着时间的推移，你会添加诸如分页，搜索，过滤，排序等一些其他代码，这些代码会让你的omni-controller真的很尴尬。

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

Answer 3

这里只需2分：

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

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

3 个答案:

TL; DR

想想“资源”，“非控制者”

约定不是物理定律