Question

我正在为类似于Twitter的客户实施活动Feed（它是唯一与当前登录用户相关的活动 - 即谁喜欢他/她的帖子，提及等等。）..它不会依赖于“推送”，但用户必须刷新页面才能看到新的活动（目前为止）。

我一直在谷歌上搜索搜索过去一小时的SO，找到实现这一目标的最佳方法，观察者不断提出解决方案。我还注意到其中许多都在使用推送通知。我注意到R Bates在他的公共活动中使用了railscast btw，这就是我问这个问题的原因。

如果我不想使用推送通知，回调可以更好甚至更好吗？您是否认为我仍然需要在rails之外使用其他东西以实现可伸缩性？（就像你可以使用“Pushapp”进行推送通知一样）

任何有关更好解决方案或光照的建议都会有所帮助。

这适用于@gg_s

我假设在这种情况下你说我有一个activity_feed表（receiver_id，sender_id，activity_type，＆amp; activity_id）（属于user，belongs_to activity_type（???），：polymorphic =＆gt; true）

# application_controller.rb

def publish_to_user_feed(message)
  current_user.activity_feed << message
end

# favorites_controller.rb

def create
  # blah blah blah
  publish_to_user_feed "This just happened."
end

在favorites_controller的“创建”操作中，“刚刚发生这种情况”可以== "@favorite.user just favorited @favorite.post by @favorite.post.user"

再一次，我希望我不会太讨厌＆amp;我很确定我所要求的是显而易见的，但我认为这将有助于我解决问题。也有助于未来的访客。

再次感谢

对于任何想要了解的人，我仍然在努力......暂时休息一下..我主要担心的是它在db＆amp;其他性能问题如果有人想要更好（使用上面的代码），请随意：）

解决方案：我不想过于复杂化，所以我正在接受ap的建议。

Answer 1

不使用。

在这种情况下，回调和观察者比你想象的更复杂。它们提供的唯一自动化是能够在模型事件时触发。而已。您有责任实施逻辑确定：

刚刚发生了什么？
应该报告吗？
要举报什么？

扩展此逻辑以支持多种类型的活动是不必要的复杂。根据需要，放弃自动化和从控制器发布活动。

创建一个帮助方法来保持DRY：

# application_controller.rb

def publish_to_user_feed(message)
  current_user.activity_feed << message
end

然后在必要时手动发布到用户的Feed：

# some_controller.rb

def some_action
  # perform some action
  publish_to_user_feed "This just happened."
end

直接从控制器报告是清晰，可读，干燥，可维护，并遵守Rails的MVC模式。没有复杂的回调链或观察者可以写。

作为奖励，在不发布活动供稿的情况下执行活动是微不足道的，例如：管理活动或用户隐私设置。

使用模型回调或观察者来实现活动源？

1 个答案: