生成控制器时仪表板会变成仪表板吗？答案

【问题标题】：Would Dashboard become Dashboards when generating a controller?生成控制器时仪表板会变成仪表板吗？
【发布时间】：2013-01-25 23:28:40
【问题描述】：

用户控制器被命名为UsersController，原因很简单，因为它控制多个用户，但实际上它不是只更改几个特定于某个用户的参数吗？

因此，对我来说最合乎逻辑的事情是控制器名称 Dashboard 应该命名为 DashboardsController，因为它控制多个 PC 上的多个 Dashboards，并且由于在呈现页面后某些特定字段的细微变化，因此它应该命名为仪表板。就像用户被命名为用户而不是用户...

这让我回到了起点。我如何决定选择什么；复数还是单数？仪表板只是应用程序中的一个特定事物，而用户并不仅仅控制他们自己，但是当用户名在页面上呈现时，仪表板都是不同的，以及特定的用户喜欢的标签。

这样做的最佳做法是什么？

【问题讨论】：

【解决方案1】：

我倾向于将演示者模式用于仪表板。仪表板是对象的混合体，很难将其视为显示或索引页面。我将创建一个虚拟对象来处理关联对象的查询和聚合。它确实清理了控制器代码，即使您决定使用 DashboardsController。

但是，我建议在路由中添加 resources.users。

collection do 
  get :dashboard
end

然后在 UsersController 下添加一个操作仪表板

def dashboard
  @presenter = UserDashboardPresenter.new(user)
end

在视图中使用@presenter。

如果您搜索演示者模式，您会发现更多信息。它非常适合缓存、代码重用、测试和性能增强。

【讨论】：

我会保留您在后台使用演示者的建议，因为这不是一个坏主意。我检查了 RailsCasts，Draper 可以很好地工作，或者我可以从头开始，但在我开始在视图中获得太多逻辑之前，我会坚持使用 Dashboard 的多元化版本。谢谢你:)
我不使用 Draper，它有点不同。我倾向于将这些类视为视图模型——它们很好地为视图封装了东西。如果您开始在控制器中看到一长串实例变量或大量基于用户的逻辑，这是清理它的一种方法。

【解决方案2】：

rails 约定是使用复数形式定义控制器名称（例如 /dashboards）。这不是一成不变的，您可以根据自己的需要进行更改，但是如果您询问最佳实践是什么，那么最好的选择是坚持使用 rails 约定，特别是如果您刚刚开始带导轨。它会让你的生活变得更简单。

如果你真的想为你的控制器使用一个单数术语（例如 /dashboard），你可以在你的 routes.rb 文件中指定它（这假设你正在使用 RESTful 路由并将仪表板定义为资源）

resource :dashboard, :controller => 'dashboard'

另外请注意，如果您决定使用单数，则需要相应地调整 rails 为 RESTful 路由创建的辅助方法，所以

  dashboards_path # will no longer work, you must use
  dashboard_path

【讨论】：

然后我会坚持仪表板的复数版本，我猜这个词并不重要：P 谢谢！
你确定吗？例如 application_controller 不是 applications_controller 因为它就像 dashboard 一个单身人士。

【解决方案3】：

对控制器使用复数名称只是 Rails 约定之一。你应该偏离约定吗？我认为坚持下去会更好。

正如您提到的用户，复数名称通常听起来更自然。我确信您的 DashboardsController 将有多个操作，因此它可以追溯到多元化的概念。

我的建议坚持复数惯例。

【讨论】：