【问题标题】:Application Dashboard View Logic应用程序仪表板视图逻辑
【发布时间】:2010-12-09 20:19:45
【问题描述】:

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

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

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

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

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

【问题讨论】:

  • 你能给我们举一个例子吗?以及动作是如何存储在每个模型中的?

标签: ruby-on-rails ruby dashboard


【解决方案1】:

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

https://github.com/jamesgolick/timeline_fu

【讨论】:

    【解决方案2】:

    按照您在第一个想法中的建议,使用单独的模型来存储提要条目。您看到的设计模式称为polymorphic association pattern

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

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

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

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

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

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

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

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

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

    【讨论】:

      猜你喜欢
      • 2010-12-29
      • 1970-01-01
      • 1970-01-01
      • 2017-08-01
      • 1970-01-01
      • 1970-01-01
      • 2015-11-10
      • 1970-01-01
      • 2011-03-18
      相关资源
      最近更新 更多