0

似乎實現驗證的最佳位置儘可能接近數據庫,所以當我使用實體框架時,最近的對象是實體,在我的情況下是POCO實體。這是一個好主意,首先在實體框架POCO實體中實現驗證嗎?

原因是,如果我想重用這個POCO實體,驗證在POCO對象中實現,然後在數據庫中插入worng數據的可能性較小。

這也避免了有人試圖在創建另一個應用程序的數據庫中插入不正確的數據,或者因爲他沒有實現驗證。所以它更安全。

一種方法是使用擴展POCO實體並實現IValidatableObject接口並返回validationresult列表的部分類。

但是其他方式如下。我有一個通用程序集,它具有以下內容:

  • 一個聲明需要實現存儲庫的方法的接口。
  • 存儲庫將使用的POCO實體。
  • 一類帶有實用程序的類,例如複製實體和驗證實體數據的方法。

然後我可以創建使用不同版本的EF或其他技術的許多存儲庫,並且所有這些存儲庫都使用通用程序集。該存儲庫使用公共庫中的方法實現驗證。

在這種情況下,我僅實現驗證一次。唯一的問題是存儲庫需要調用方法來驗證數據。

但是從我的角度來看,這種方式有很多優點。例如,我可以根據操作的類型驗證實體的數據。例如,如果我添加一條新記錄,並且主鍵爲自動數字,如果ID不是0,那麼我可以拋出一個異常,或者如果我在ID爲0時嘗試刪除一個寄存器,那麼我不會'不需要將命令發送到數據庫。

因此,第二個解決方案解決了實現驗證儘可能接近數據庫的問題,在存儲庫中使用了bacause,即訪問數據庫的元素,但存在如果某些開發人員創建新的存儲庫,而不使用驗證方法,我可以在數據庫中有不正確的數據。

所以我的問題是,如果最好的選擇是使用部分類的驗證或使用公共庫,並驗證在存儲庫中實現,那真正是用戶將使用。

謝謝。

回答

1

好的 - phew,大問題。我的意見是,應用程序的應用程序領域是一切的老闆。數據庫只是一個附加服務。所以,應用程序域應該最終驗證所有正在SENT某處的對象。沒有必要驗證從數據庫中傳出的對象,因爲它們已經過驗證。

作爲示例,如果您創建的某個對象需要發送到Web服務並且需要驗證,該怎麼辦。可以說,它永遠不會靠近數據庫或存儲庫。一旦DOMAIN業務對象得到驗證,就可以將其發送到持久性或其他任何地方。

要考慮的另一件事是你的意思是驗證。這是否意味着數據類型是正確的?這是否意味着業務對象是有效的?這是否意味着業務對象在給定的上下文中是有效的?它可能意味着所有或僅僅是這些事情中的一部分。

舉一個例子,如果你的系統允許用戶部分更新記錄(通常有很長的輸入表單)會怎麼樣。業務對象只有在捕獲所有必需數據時纔有效,但數據庫允許持續存在「部分」數據。換句話說,您可以將業務對象保存到數據庫,儘管它尚未進行進一步處理。等等...