应用程序仪表板查看逻辑
Gar*_*ett 7 ruby dashboard ruby-on-rails
在我的应用程序中,我想在登录时提供类似屏幕的仪表板,以便了解正在发生的事情.我有大约4个模型需要从中收集数据并按顺序排序.我的问题是知道的动作,这样我就可以得到每个模型的特定字段.
这里有一些关于如何去做的想法,但我觉得它们不是最好的和不完整的.
我有一个单独的模型,其中包含:model,associated_id,action."Post,1,created"就是一个例子.
有4个不同的数组,并通过说明将它们与正确的顺序合并
created_at.
最好的方法是什么？我在下面提供了一个例子:
按照您在第一个想法中的建议，使用单独的模型来存储提要条目。您看到的设计模式称为多态关联模式
假设这个新模型称为 Feed，遵循多态关联模式，您将使用以下列： feedable_type 和 feedable_id （与建议的列名称 model 和 Associated_id 相对应）
我确实必须承认，您的问题比对多态关联的简单理解要大，提要是现代信息设计的一项重大创新，并且需要许多复杂的功能，包括：
- 隐私
- 关注/订阅
- 过滤
- 合并
根据这些属性中的任何一个，所有这一切都可能变得更加复杂。如果您必须满足一些非功能性要求（例如扩展和性能），那么头痛很快就会加剧。
如果您曾经构建过 Facebook 应用程序，那么了解他们的 feed 发布 API 的工作原理会很有启发。
您很快就会注意到，用于存储提要的单独模型完全无法渲染提要条目 HTML，但加载能够很好地渲染 HTML 的原始模型的数据库成本很高。为了解决这个问题，我让原始模型呈现提要的 HTML，并将其存储到提要表中。
当然，实现比这还要复杂一些。与 Facebook 一样，所有提要都有 1 个共同点（它们来自人）。所以每个 feed 条目都有 user_id （可以这么说）。由于我们知道所有提要都具有此数据并且可以渲染新闻提要的“谁做的”部分，因此我们不会预渲染该部分。
尽可能多地预渲染是非常有帮助的，这在以后很难从 feed 模型中重新构建，但是当我们确定该组件无处不在并且被塞进我们的 feed 模型中时，请延迟预渲染。
最后，研究开源项目是一个很好的学习方式
| 归档时间： |
|
| 查看次数： |
921 次 |
| 最近记录： |