我有一個架構問題。我試圖建立一個ASP.MVC Web應用程序使用依賴注入來分離數據訪問層。問題是 - 模型。解耦ASP.MVC和數據訪問層與依賴注入
基本上我有兩個解決方案。第一個是MVC Web應用程序，第二個是數據訪問層。 DAL具有一些接口，由Entity Framework生成的實現和模型，以及一些其他模型 - 搜索條件和結果。 MVC在使用Ninject注入DAL的基本控制器中有一個屬性。
我的擔心是 - 我該如何處理模型？
我使用依賴注入的原因是將DAL與主Web應用程序解耦。因此，如果我正確理解DAL應該易於連接/拆卸的想法。但是，如果我在MVC控制器中使用DAL的模型，並且它將完全依賴於DAL中的細微變化。
我在MVC中創建了複製實體框架生成模型的模型，所以我可以在MVC中使用這些MVC模型，並在調用DAL方法之前使用AutoMapper將它們映射到DAL模型，因此僅使用DAL模型在控制器和耦合器中更鬆散。但它似乎仍然很髒，遠非優雅的解決方案。
您認爲如何？有什麼辦法以更聰明的方式處理它？
將您的模型放入一個Common和UI，它們都是UI和DAL引用的。如果你的DAL改變了，你可以讓它返回Common中的現有模型，而不需要改變你的UI。或者，如果您更改了用戶界面，您的新用戶界面可以引用Common.dll並與現有模型一起工作。如果您以後需要添加API，API將只引用Common.dll（或任何您想要調用它）。
編輯：這是假設您不會將EF模型從DAL返回到您的UI。 UI使用視圖模型，DAL使用EF模型，兩者之間的AutoMapper地圖。
你是對的。將數據庫模型直接傳遞給View Engine並不是一個好主意。由於數十個原因（包括性能，潛在的信息泄露，耦合等），不推薦這樣做。
我不認爲將您的數據庫模型映射到視圖模型1：1是一個好主意。推薦的方法是讓視圖模型僅表示您在特定視圖中需要的最小值。有一些開銷需要不斷地將數據模型映射到您的視圖模型，以準確提取您在某些視圖上需要的內容，但這對於獲得清潔和精益視圖模型來說是非常必要的。
下面是一些建議如何在ASP.NET MVC使用視圖模型：
ASP.NET MVC - How exactly to use View Models
從上面的線程報價克里斯·普拉特：
這是個視圖模型進來。MVVM（模型 - 視圖 - 視圖模型）是一種與MVC有點平行的模式，它認識到單一模式到規則全部方法的固有問題。這裏我不會詳細討論，因爲MVC不使用這種模式。但是，大多數ASP.NET MVC開發人員已經選擇了MVVM的View Model。你實際上最終得到的是一個數據庫支持的實體（傳統模型），然後通常是許多不同的視圖模型，代表不同的狀態下的實體。這允許您的模型包含與持久性相關的業務邏輯，而視圖模型包含與顯示，創建和更新模型相關的業務邏輯。
非常好的主意。總結 - 我試圖解耦太多;）。我不知道的事情很簡單 - 模型是合同的一部分，是界面的一部分，所以它們不能輕易改變。但有些事情我不確定。請糾正我，如果我錯了 - 當我移動模型到普通的我應該 - 在使用EF的情況下 - 重複的實體生成的模型並將它們映射到DAL中，對嗎？我的意思是 - DAL接口應該使用通用的模型（即使它只是實體/表模型）。 – Landeeyo 2014-09-25 08:52:31
像下面的答案一樣，「有一些開銷需要不斷地將您的數據模型映射到您的視圖模型，以準確提取您在某些視圖上需要的內容」。 DAL內部使用EF模型，如用戶數據模型，具有後期綁定和負載屬性以及虛擬集合，但不包括UI，但UI請求UserEmailViewModel（駐留在Common.dll中），DAL將從其數據模型映射UserEmailViewModel並只返回用戶名和電子郵件。所以是的，DAL界面應該返回並在Common.dll中創建模型。它如何映射它們取決於DAL，UI並不在意。 – artm 2014-09-25 09:05:35