6

我有一个带有 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
4

3 回答 3

8

TL;博士

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

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

想想“资源”，而不是控制器

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

约定不是物理定律

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

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

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

于 2013-09-26T23:10:07.387 回答
4

除非您有充分的理由，否则您应该坚持使用常规名称，如index、等。是什么？它看起来和我一模一样。请记住，您可以通过操作路由表来使操作的路径成为您想要的任何名称，但在内部它应该是一致的并遵循约定以确保它是可维护的。newshowdashboardindexindex

需要注意的是，除了一开始之外，您的控制器很少这么简单。随着时间的推移，您将添加分页、搜索、过滤、排序和一堆其他代码，这些代码会让您的全能控制器非常尴尬。

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

于 2013-09-26T22:54:36.177 回答
1

这里简单说两点：

  1. 仅当您对相关模型有请求操作时，您才需要一个控制器；
  2. 当模型仅用于数据计算和基本业务逻辑实现时，不要生成控制器。
于 2013-09-27T02:43:52.013 回答