ruby-on-rails - 应用程序仪表板视图逻辑

Question

在我的应用程序中，我想在他们登录时提供一个类似屏幕的仪表板，以了解正在发生的事情。我有大约 4 个模型需要从中收集数据并将它们排序。我的问题是知道动作，所以我可以获得每个模型的特定字段。

这里有一些关于如何去做的想法，但我觉得它们不是最好的，充其量是不完整的。

1. 我有一个单独的模型，其中包含：模型、关联 ID、操作。“发布，1，创建”就是一个例子。

2. 有 4 个不同的数组，并通过 say 将它们以正确的顺序合并created_at。

解决此问题的最佳方法是什么？我在下面提供了一个示例：

Answer 1

您可能想查看 rails 的 timeline_fu 插件：

https://github.com/jamesgolick/timeline_fu

Answer 2

按照您在第一个想法中的建议，使用单独的模型来存储提要条目。您看到的设计模式称为多态关联模式

假设这个新模型称为 Feed，遵循多态关联模式，您将使用以下列：feedable_type 和 feedable_id（与您建议的列名 model 和 associated_id 相对）

我不得不承认，您的问题不仅仅是对多态关联的简单理解，提要是现代信息设计的一项重大创新，并且需要许多复杂的功能，包括：

• 隐私
• 关注/订阅
• 过滤
• 合并

根据这些属性中的任何一个，所有这些都可能变得更加复杂。而且，如果您必须满足一些非功能性要求，例如扩展和性能，那么令人头疼的问题会很快变得复杂。

如果您曾经构建过 Facebook 应用程序，那么看看他们的提要发布 API 是如何工作的会很有启发性。

您会很快注意到，用于存储提要的单独模型完全无法呈现提要条目 HTML，但是加载能够很好地呈现 HTML 的原始模型的数据库成本很高。为了解决这个问题，我让原始模型渲染提要的 HTML，并将其存储到提要表中。

当然，实现甚至比这复杂一点。与 Facebook 一样，所有提要都有 1 个共同点（它们来自人）。所以每个提要条目都有 user_id （可以这么说）。由于我们知道所有提要都有这些数据并且可以呈现新闻提要的“谁做的”部分，所以我们不会预呈现该部分。

尽可能多地进行预渲染是非常有帮助的，这在以后很难从提要模型中重新构建，但是当我们确定组件无处不在并被塞进我们的提要模型时延迟预渲染。

最后，学习开源项目是一种很好的学习方式

• 爱少