【发布时间】：2011-11-23 21:49:58
【问题描述】：
我想要一个仪表板页面，该页面将来自多个模型的信息收集到一个摘要视图（没有自己的模型）。我应该如何以 Rails 方式处理它？我应该只使用索引操作创建一个dashboard_controller 吗？
谢谢。
【问题讨论】：
-
可能想看看activeadmin.info。
标签： ruby-on-rails model-view-controller controller dashboard
【发布时间】：2011-11-23 21:49:58
【问题描述】：
只是想少一点 Rails。我假设您的仪表板主要包含小部件？即一些自包含的元素，无论如何？为什么不让这些小部件成为您的模型（不是基于 AR 的）。将所有逻辑和数据检索封装在小部件模型中。所以现在如果你想使用 RESTful，你可以使用 WidgetsController 和 index 操作作为仪表板。在第二步中，您可以使用显示操作为仪表板的 AJAX 部分的每个小部件提供 JSON 数据。等等。
请记住 REST 不一定 == CRUD，并且模型不需要是 ActiveRecord 模型。 Rails 迫使您进入 MVC 模式，这是一件很棒的事情，并且即使编写糟糕的 Rails 应用程序也比那里的许多 PHP 混乱更好，但有时我们往往会忘记在 ActionController + ActiveRecord 等之外还有很多可能性.
【讨论】：
-
谢谢玛丽安。您能否详细说明为什么使用小部件偏离 Rails 会是一个不错的选择？
-
我认为他想说的是在模型中封装应用程序的行为，这将是一个坏主意。业务逻辑可以放在模型中，但是如果它与数据存储和检索无关，则需要将其放在控制器中。
-
我强烈反对。首先，数据持久性是模型的一层，它不是定义模型的东西。您可以拥有很多模型而无需持久性。并且您应该始终将业务逻辑封装到您的模型中，只需遵循良好的 OOP 原则。仅仅因为 Rails 为我们提供了一种很好但固执己见的做事方式，这并不意味着我们必须忘记所有面向对象。 WidgetsController 的目的是加载和渲染一个/几个小部件。它不需要知道小部件是什么。在这个控制器中查询 20 个不同的表会很尴尬。
-
也就是说，如果您只是将这 20 个查询放入 Widget 模型中的一个函数中，您将一无所获。但是你可以围绕它构建一个适当的类结构，考虑对象和关系，而不是“我需要什么表中的什么数据”。
你想要看看管理框架，看看它是否能解决你的需求，我喜欢Typus 和RailsAdmin 否则你会想看看presenter pattern 以及它是如何应用的到 Rails 和您的应用程序。仪表板基本上只会与您现有的模型和控制器逻辑接口，因为您不想最终遇到每个模型有两组逻辑的情况。虽然我链接到的博客是 2007 年的，但您应该能够从中提取一些有用的信息并了解您需要做什么。
如果您有任何问题，请随时提出。
【讨论】：
-
非常感谢，德文。我只在同时为多个模型创建对象的上下文中了解 Presenter。你能解释一下它在我的情况下的潜在好处（主要是展示）吗？
-
您希望与应用程序的大部分进行交互，因此此模式旨在保持代码 DRY 并委派职责。通常，您保留相同的 CRUD 操作并将它们委托出去，我也会使用部分操作，以便您尽可能共享视图代码。
-
谢谢德文。我会试试你的方法。
-
嗨，Devin，我想邀请您在此处加入有关实施演示者的后续讨论：stackoverflow.com/questions/7537180/…。谢谢。
-
“使用库”在我看来不是一个很好的答案。
我应该创建一个仅包含索引操作的dashboard_controller 吗？
我更喜欢将不执行 CRUD 的页面放在 application_controller 中的模型（例如仪表板）上。无需创建dashboard_controller。
【讨论】：
-
这会在 application_controller 中造成很多混乱。尤其是当涉及到 ajax 时，这可能与仪表板有关，或者在开发非典型应用程序时。
-
@providence 我完全同意。这个答案只是为了解决 OP 的情况，他正在考虑“只是一个索引操作”，他将显示来自“多个模型”的“摘要”信息。
-
我使用一个仪表板控制器，我们有多个仪表板，因此 index 操作列出了可用的仪表板，而显示操作是仪表板本身。
这会是Presenter pattern 的用例吗？
我即将实现一个 ddashboard，这是我认为可以带来可维护代码库的最佳设计。
【讨论】：
-
当我看到创建不符合 RESTful 约定（索引、新建、创建、显示、编辑、更新、销毁）的控制器操作的建议时，出于本能，我惊恐地退缩了。有没有办法按照 REST 方法构建这类页面？
我的解决方案是运行
rails g controller Dashboards
然后手动创建一个 app/models/dashboard.rb 模型，内容可以少到
class Dashboard end
当然模型你可以把所有你需要的逻辑从其他模型中捞出。
回到控制器，你只创建了索引动作。最后，您手动创建 app/views/dashboards/index.html.erb 文件，其中包含您需要的任何内容。添加路线，您就可以开始了。如果您注意细节，您可以将 url 从 /dashboards 更改为 /dashboard。就是这样，我认为它非常 Rails-y。
【讨论】：
-
这绝不是他的问题的解决方案，你所描述的只是铁轨脚手架......
-
Rails 中的脚手架意味着自动生成所有 MVC 堆栈，我的答案中没有看到。该解决方案正是我为类似要求实现它的方式，并且确实有效。仅仅因为它是基本的并不意味着它是错误的。由于 OP 没有指定他的 Rails 级别，因此基本解决方案是可以接受的。我没有找到更好的“使用一个臃肿的框架并希望它能工作”的公认答案。