我正在以一种模型(OrigM)拆分为两个模型(OrigM,NewM)的方式重构我的Rails 5.2应用程序。在代码库中,有对OrigM对象执行update
的代码,我现在希望这会导致特殊的行为,其中相关的OrigM和NewM对象将得到适当更新。
执行此操作似乎很简单,就是在OrigM模型中覆盖update
,但尝试以简单的方式进行操作会导致无限递归,因为显然甚至在类方法OrigM.update(id, new_attrs)
下引擎盖只是find
将ID为id
的对象并调用update
作为其实例方法。
尽管我尚未对它们进行全面测试,但我想出了一些其他可行的方法:(1)通过分别对它们调用write_attribute
来更新OrigM属性(似乎不会这样)让我检查验证),或(2)
self.assign_attributes(new_attrs) ## resulting in "dirty" object, then
self.save!
我倾向于第二种解决方案,因为它似乎应该在功能上与标准update
所做的工作完全相同。
编辑: 我意识到除非有人问一个问题,否则没有人能真正地回答,所以现在将其重铸为:
问题:是否应该覆盖AR的update
方法(在OrigM类中)?
评论员说:“不要这样做,否则您会受到谴责”(说实话,我确定有人会笑)。但是...真的是这样的罪行吗?是否有“杀手级”理由不这样做(您无法与之抗争)?还是只是勉强鼓励的最佳做法?
还:“为什么不做一个不同的事情就不定义一个新方法呢?”好吧...我想我需要对模型做更多的介绍...我不想尝试给出实际的代码,因为它太复杂了。可以说:大多数代码仍然与OrigM对象交互,并且不会了解NewM。仅在体系结构上需要NewM,因为我需要允许多个OrigM共享(属于)单个NewM,以避免数据重复。因此,我想让其余大部分代码保持这种幻觉,即仍然只有OrigM,并且能够照常进行更新。这感觉对我来说是最优雅的解决方案。如果我创建一个新的OrigM#myupdate
,将来的开发人员(包括我自己)可能会诅咒我,因为他们试图做一个简单的update
,但事情却变得很糟糕。哇,不是必须要知道有一个特殊的更新功能,就像必须知道AR的更新已被覆盖一样令人困惑吗?