ASP.NET MVC和ADO.NET實體框架

Question

我有一個問題，我無法解決沒有一些建議。我正在開發一個ASP.NET MVC應用程序，並使用ADO.NET EF連接到數據庫。我的問題是，我不知道我的應用程序的業務邏輯是否應該使用由EF創建的實體，或者是否應該創建一個抽象層並將EF實體與業務邏輯對象分開（並在這些對象類型之間開發一些轉換器）。或者，也許我完全錯了，我應該以不同的方式做？怎麼樣？哪種解決方案是最佳實踐？

Answer 1

這絕對取決於您的應用程序，其範圍和要求。僅僅爲了層的目的而引入抽象層意味着引入複雜性和間接性，在這種情況下，它往往並不能真正幫助你。對於分層架構的過度使用，術語千層麪軟件目前正在引入 - 取代臭名昭着的意大利麪條軟件。

爲了說明這一點，我不提議反抽象層。使用它們高度取決於您的具體要求。

我會從一個簡單的體系結構開始，根據需要添加圖層以確保可測試性和可維護性。當前版本實體框架（4.1截至發稿時）允許正與波蘇斯和DbContext非常類似的工作模式庫和單位。這些開箱即用的功能可能足以在大多數情況下啓動。

Answer 2

我已經通過爲Data類和Model類分開項目來處理類似的情況。

Data類將是由您的ADO.net模型生成的，然後您可以使用Repository模式連接到ADO.net上下文，檢索數據類並使用類似http://automapper.codeplex.com/的東西來映射數據類到商業模式。

這將允許您在模型上使用MVC驗證（例如Required，Regex等），並避免與Data類混淆，並且只傳遞模型。

Answer 3

一般來說，我最好將業務邏輯放在域模型和服務層中。領域模型中的邏輯是可取的，因爲它更容易測試，但並不是所有的邏輯都很容易以這種方式實現。例如。當一個操作涉及許多域對象時，你不能總是合理地將它放在其中一個域中而不會影響性能和其他問題。

Answer 4

這是POCO發揮作用的地方。您可以從您的數據模型生成通用POCO，並將其用於業務層。 EF將創建POCO並跟蹤它們。

的這裏的想法是，你的POCO的只是實體，而不是EF對象（雖然EF確實，在幕後創建您POCO的代理版本）