2017-06-20 102 views
0

我试图执行一些额外的清理代码,当一个允许软删除的模型被删除。即使模型已经(软)删除Laravel发射删除的事件

我已经迷上了“已删除”事件执行此清理代码如下:

protected static function boot() 
{ 
    parent::boot(); 

    static::deleted(function ($mymodel) { <cleanup code here> }); 
} 

但是我发现,如果删除被称为上已经删除模式,删除事件会再次发射。我希望在框架中有一个检查来防止这种情况发生,但它似乎不适合软删除模型?

编辑:我没有那么多想讨论是否调用软删除记录上的删除应该/不应该再次触发删除事件。我猜想会有不同的意见。事实是,它目前确实,我的要求是它没有,所以这是更多的下一部分围绕如何稳健地实施我需要一些帮助的检查:

如果我必须实施我自己检查这一点,是否可以重写模型上的删除方法 - 或者还有其他方式可以删除模型?我对这一点的关注是为什么我首先听取删除的事件来运行清理代码 - 而不是重写delete方法,并在调用parent :: delete()之后放置我的清理代码,因为我认为应该调用delete事件,而不管模型的删除是如何启动的(如果确实有多种方式?)。

+1

你首先在已经删除的模型上调用'delete()'的原因是什么? – lesssugar

+0

是的,这是我在构建/调试前端时遇到的问题,所以不要同意首先发生的事情。不过,我正在使用delete事件来替代传统上可能通过数据库触发器所做的事情,所以我希望数据库和对象模型稳固可靠,并且不易受前端中的错误影响。我有点像查看属性设置器,传统上在将值设置为X并可能触发更改的事件之前检查属性的值不是X. – madz

回答

0

允许类中的某个方法的响应性依赖于允许的触发器,因此您不应在视图中启用此类机制。

记录的'已删除'状态自己定义代码/视图不会将对象暴露给'删除'消息,除非它有另一个允许在域中的行为/规则。这是你定义对象域的规则,所以你要决定什么时候可以发生。

举例来说,软删除可能允许第二次删除呼叫硬删除记录,例如,所以固定电话不应该限制通话。

+0

我知道您正在进行一般性争论,而我在某些情况下,我同意,但是在这种情况下感觉这是有点延伸,因为软删除记录是明确定义的行为,并且事件触发以指示记录已经改变状态。如果它已经处于删除状态,并且您再次删除它,则看起来错误的是另一个已删除的事件会因为第二个调用未改变记录的状态而触发。如果想要硬删除记录,则forceDelete方法存在。同样,如果删除不使用软删除的模型多次删除,则第二次调用将不会触发事件。 – madz

+0

可以找到一个软删除的记录,并且是预测的行为,因为例如可以通过回顾记录来处理该记录。到目前为止,它很容易接收到消息。关键是'删除'是软删除记录的可接受消息,另一方面,硬删除记录不存在 –