最佳實踐，以實現業務邏輯的驗證 - 實體框架

Question

我使用實體框架是第一次，我需要插入新對象到數據庫之前添加業務邏輯，這裏是我想過的選項：

通過在實現驗證層的自定義類使用OnPropertyChanging局部方法

裹所生成的代碼重寫SaveChanges方法

實現業務邏輯爲每個實體 -

1. 實現對DataContext的級別的業務邏輯。

對實體框架管理業務邏輯時

Answer 1

看看validation with EF - 驗證是在實體內部進行的。

這是一個非常乾淨的方式來組織您的項目。

當您有POCO s時，實體驗證的明顯位置在POCO本身中。

有意義的是，Customer對象的任何驗證實際上都在Customer類中。

Answer 2

也許你的答案矗立在放入系統線路哪種方法是最好的做法;）

Best practice entity validation in ASP.NET MVC & ADO.NET Entity Framework

Answer 3

另一種方式要考慮的是完全組件化你的數據訪問層完全來自業務邏輯層。

創建一個只能直接訪問實體框架的數據訪問接口，然後在一個單獨的項目中，我將創建您的業務邏輯類，它通過接口與數據訪問層進行交互。您的業​​務邏輯項目中沒有實體框架參考。

通過這種方式，這些圖層被組件化，並且更易於作爲用於兩層或三層訪問的多個程序集進行分發。

Answer 4

也許嘗試閱讀有關Specification pattern

Answer 5

我的經驗：

1. 這工作，但它是相當不少，其中必須驗證這可以慢許多實體的情況下工作，。其實EFv4.1會自動完成此操作。
2. 我不喜歡這種方式 - 它只服務於單個屬性更改，不適用於需要在獲取有效狀態之前修改多個屬性的複雜驗證。
3. 也許 - 我喜歡根據需求進行驗證。每個實體都可以暴露Validate方法來檢查整個實體的狀態是否正確。

但是，只有您總是使用整個實體，所有這些纔有效。一旦開始使用部分更新和其他功能，您仍然需要在別處處理驗證。這是另一個用於驗證需求的+1。

Answer 6

我更喜歡數字3的一個版本。我喜歡抽象實體框架using a repository或類似的東西，以防我將來/需要替換EF。然後對於驗證/業務邏輯，我使用任何驗證技術對應用程序有意義，但通常是DataAnnotations（用於UI最小驗證）和驗證框架（如Fluent Validation）的最大驗證/業務規則的組合。這個驗證/業務邏輯同時存在於實體類（DataAnnotations）和抽象層中，這通常是我的應用程序中的一個服務層。

Answer 7

您可以通過創建另一個部分類定義來擴展您的類，大多數EF模板將實體定義爲僅供人們輕鬆擴展它們的部分定義。如果你正在使用WPF或Silverlight，因爲大多數東西不是直接綁定的，你可能想要這樣做，你可能有一個布爾值並想將其轉換爲顏色等。編寫轉換器速度很慢，需要更多的代碼然後在您的BusinessObjects上創建新的Getter。

我們一直在使用EF 4.0 STE（Self Tracking Entities）一段時間，並且我們用自己的部分定義擴展了大部分。我們改變了一些創建STE的T4模板，以允許訪問自定義部分類定義上的構造函數以及其他小改進。

Answer 8

從Visual Studio雜誌文章解決這個問題：

http://visualstudiomagazine.com/articles/2012/04/01/integrating-validation-with-the-entity-framework.aspx