随着Observers正式removed from Rails 4.0,我很好奇其他开发人员在他们的位置使用什么 . (除了使用提取的宝石 . )虽然Observers肯定被滥用并且有时很容易变得笨拙,但是在缓存清除之外有许多用例,它们是有益的 .
例如,需要跟踪模型更改的应用程序 . 观察者可以轻松地观察模型A的变化,并在数据库中记录模型B的变化 . 如果你想观察几个模型的变化,那么一个观察者就可以处理它 .
在Rails 4中,我很好奇其他开发人员使用什么策略代替Observers来重新创建该功能 .
就个人而言,我倾向于某种“胖控制器”实现,在每个模型控制器的创建/更新/删除方法中跟踪这些更改 . 虽然它稍微膨胀了每个控制器的行为,但它确实有助于可读性和理解,因为所有代码都在一个地方 . 缺点是现在的代码非常相似,分散在几个控制器中 . 将该代码提取到帮助器方法是一种选择,但您仍然可以调用遍布各处的方法 . 不是世界末日,也不是“精瘦控制者”的精神 .
ActiveRecord回调是另一种可能的选择,虽然我个人并不喜欢,因为在我看来它往往会将两个不同的模型紧密地结合在一起 .
所以在Rails 4中,no-Observers世界,如果你必须在创建/更新/销毁另一条记录之后创建一条新记录,你会使用什么样的设计模式?胖控制器,ActiveRecord回调,还是完全不同的东西?
谢谢 .
12 回答
看看Concerns
在models目录中创建一个名为concern的文件夹 . 在那里添加一个模块:
接下来,在您希望运行after_save的模型中包含:
根据你正在做的事情,这可能会让你在没有观察者的情况下接近 .
他们现在在plugin .
我还可以推荐an alternative,这将为您提供如下控制器:
我的建议是在http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html阅读詹姆斯·戈利克的博客文章(试着忽略 Headers 听起来多么不正确) .
回到那一天,这一切都是“肥胖的模特,瘦小的控制者” . 然后脂肪模型成为一个巨大的头痛,特别是在测试期间 . 最近推出的是瘦模型 - 这个想法是每个类应该处理一个责任而模型的工作就是将数据保存到数据库中 . 那么我所有复杂的业务逻辑最终会在哪里结束?在业务逻辑类中 - 表示事务的类 .
当逻辑开始变得复杂时,这种方法可能变成泥潭(giggity) . 这个概念虽然合理 - 而不是使用难以测试和调试的回调或观察器隐式触发事物,而是在模型顶层逻辑层的类中显式触发事物 .
使用活动记录回调只会翻转耦合的依赖关系 . 例如,如果您有
modelA
和CacheObserver
观察modelA
rails 3样式,则可以删除CacheObserver
,没有任何问题 . 现在,相反说A
必须在保存后手动调用CacheObserver
,这将是rails 4.您只需移动依赖项,这样就可以安全地删除A
但不是CacheObserver
.现在,从我的象牙塔,我更喜欢观察者依赖于它所观察的模型 . 我是否足够关心我的控制器?对我来说,答案是否定的 .
大概你已经考虑了为什么你想要/需要观察者,因此创建一个依赖于它的观察者的模型并不是一个可怕的悲剧 .
对于依赖于控制器动作的任何类型的观察者,我也有(合理的基础,我认为)厌恶 . 突然之间,您必须将观察者注入任何可能更新您想要观察的模型的控制器动作(或其他模型) . 如果您可以保证您的应用程序只会通过创建/更新控制器操作修改实例,那么您将获得更多权力,但这不是我对轨道应用程序的假设(考虑嵌套表单,模型业务逻辑更新关联等)
Wisper是一个很好的解决方案 . 我个人对回调的偏好是他们想要在我在测试中设置模型时触发回调但是我确实希望它们被解雇无论何时涉及控制器 . 使用Wisper非常容易设置,因为您可以告诉它只能监听块内的事件 .
在某些情况下,我只是使用Active Support Instrumentation
我对Rails 3 Observers的替代方案是一个手动实现,它利用模型中定义的回调但管理(如上面的答案中的agmin所述)“翻转依赖...耦合” .
我的对象继承自一个提供注册观察者的基类:
(当然,根据继承的组合精神,上面的代码可以放在一个模块中并混合在每个模型中 . )
初始化程序注册观察者:
然后,除了基本的ActiveRecord回调之外,每个模型都可以定义自己的可观察事件 . 例如,我的用户模型公开了2个事件:
任何希望接收这些事件通知的观察者只需要(1)向暴露事件的模型注册,(2)有一个名称与事件匹配的方法 . 正如人们所料,多个观察者可以注册同一事件,并且(参考原始问题的第2段)观察者可以观察多个模型中的事件 .
下面的NotificationSender和ProfilePictureCreator观察者类定义了各种模型公开的事件的方法:
需要注意的是,所有模型中暴露的所有事件的名称必须是唯一的 .
我认为观察员被弃用的问题并不是观察者本身就是坏人,而是他们被滥用了 .
我会提醒你不要在你的回调中添加太多逻辑,或者只是在已经找到Observer模式这个问题的合理解决方案的情况下移动代码来模拟观察者的行为 .
如果使用观察者是有意义的,那么一定要使用观察者 . 只需了解您需要确保您的观察者逻辑遵循声音编码实践,例如SOLID .
如果你想将它添加回你的项目,观察者宝石可以在rubygems上使用https://github.com/rails/rails-observers
看到这个简短的线程,虽然没有全面的全面讨论,我认为基本论点是有效的 . https://github.com/rails/rails-observers/issues/2
你可以试试https://github.com/TiagoCardoso1983/association_observers . 它尚未针对rails 4(尚未启动)进行测试,需要更多协作,但您可以检查它是否适合您 .
如何使用PORO代替?
这背后的逻辑是你的“额外保存行动”可能是商业逻辑 . 我喜欢将两个AR模型(应该尽可能简单)和控制器(这些都很难以正确测试)分开
简单地称之为:
您甚至可以通过注入额外的保存后操作对象来扩展它
并举例说明'额外' . 你可能想稍微调整一下:
如果您喜欢这种方法,我建议阅读Bryan Helmkamps 7 Patterns博客文章 .
编辑:我还应该提到上述解决方案允许在需要时添加事务逻辑 . 例如 . 使用ActiveRecord和受支持的数据库:
值得一提的是,Ruby标准库中的Observable模块不能用于类似活动记录的对象,因为实例方法
changed?
和changed
将与ActiveModel::Dirty中的方法冲突 .Bug report for Rails 2.3.2
我有同样的问题!我找到了一个解决方案ActiveModel :: Dirty,因此您可以跟踪您的模型更改!
http://api.rubyonrails.org/classes/ActiveModel/Dirty.html