即使模型已經（軟）刪除Laravel發射刪除的事件

我試圖執行一些額外的清理代碼，當一個允許軟刪除的模型被刪除。即使模型已經（軟）刪除Laravel發射刪除的事件

我已經迷上了「已刪除」事件執行此清理代碼如下：

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

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

但是我發現，如果刪除被稱爲上已經刪除模式，刪除事件會再次發射。我希望在框架中有一個檢查來防止這種情況發生，但它似乎不適合軟刪除模型？

編輯：我沒有那麼多想討論是否調用軟刪除記錄上的刪除應該/不應該再次觸發刪除事件。我猜想會有不同的意見。事實是，它目前確實，我的要求是它沒有，所以這是更多的下一部分圍繞如何穩健地實施我需要一些幫助的檢查：

如果我必須實施我自己檢查這一點，是否可以重寫模型上的刪除方法 - 或者還有其他方式可以刪除模型？我對這一點的關注是爲什麼我首先聽取刪除的事件來運行清理代碼 - 而不是重寫delete方法，並在調用parent :: delete（）之後放置我的清理代碼，因爲我認爲應該調用delete事件，而不管模型的刪除是如何啓動的（如果確實有多種方式？）。

來源

2017-06-20 madz

你首先在已經刪除的模型上調用'delete（）'的原因是什麼？ – lesssugar

是的，這是我在構建/調試前端時遇到的問題，所以不要同意首先發生的事情。不過，我正在使用delete事件來替代傳統上可能通過數據庫觸發器所做的事情，所以我希望數據庫和對象模型穩固可靠，並且不易受前端中的錯誤影響。我有點像查看屬性設置器，傳統上在將值設置爲X並可能觸發更改的事件之前檢查屬性的值不是X. – madz

允許類中的某個方法的響應性依賴於允許的觸發器，因此您不應在視圖中啓用此類機制。

記錄的'已刪除'狀態自己定義代碼/視圖不會將對象暴露給'刪除'消息，除非它有另一個允許在域中的行爲/規則。這是你定義對象域的規則，所以你要決定什麼時候可以發生。

舉例來說，軟刪除可能允許第二次刪除呼叫硬刪除記錄，例如，所以固定電話不應該限制通話。

來源

2017-06-20 09:07:23

我知道您正在進行一般性爭論，而我在某些情況下，我同意，但是在這種情況下感覺這是有點延伸，因爲軟刪除記錄是明確定義的行爲，並且事件觸發以指示記錄已經改變狀態。如果它已經處於刪除狀態，並且您再次刪除它，則看起來錯誤的是另一個已刪除的事件會因爲第二個調用未改變記錄的狀態而觸發。如果想要硬刪除記錄，則forceDelete方法存在。同樣，如果刪除不使用軟刪除的模型多次刪除，則第二次調用將不會觸發事件。 – madz

可以找到一個軟刪除的記錄，並且是預測的行爲，因爲例如可以通過回顧記錄來處理該記錄。到目前爲止，它很容易接收到消息。關鍵是'刪除'是軟刪除記錄的可接受消息，另一方面，硬刪除記錄不存在 –

即使模型已經（軟）刪除Laravel發射刪除的事件

回答

相關問題