ASP.NET MVC：使用EF實體作爲視圖模型？

Question

可能重複：
ASP.NET MVC - Linq to Entities model as the ViewModel - is this good practice?

是正常使用EF實體類在ASP.NET MVC視圖模型？

如果viewmodel與EF實體類的90％相同怎麼辦？

假設我在實體框架模型中有一個Survey類。它有90％符合查看編輯所需的數據。 與視圖模型應具有的唯一區別 - 是要使用一個或多個屬性（這是填充Survey對象所必需的，因爲EF類不能直接映射到它的屬性表示方式（子複選框，廣播組，等等））

你使用ViewData []傳遞它們嗎？或者用新的附加屬性創建一個Survey類（SurveyViewModel）的副本（它應該能夠將Survey中的數據複製並返回給它）？

編輯： 我也試圖避免使用Survey作爲SurveyViewModel屬性。當使用UpdateModel或使用默認聯編程序更新某些Survey屬性時，使用SurveViewModel控制器中的SurveillanceModel自定義屬性，而其他（不能直接映射到實體）時，它會顯得很奇怪。

Answer 1

我喜歡使用Jimmy Bogard's approach，視圖和視圖模型之間始終保持1：1的關係。換句話說，我不會將我的領域模型（在這種情況下是您的EF實體）用作視圖模型。如果你覺得你正在做很多工作之間的映射，你可以使用像AutoMapper這樣的工作爲你做。

Answer 2

在較大的項目中，我通常會將數據對象中的業務對象作爲樣式來分割。讓程序和數據庫都變化並且僅影響控制（或VM）層是一種更簡單的方法。

Answer 3

有些人不喜歡將這些模型類一直傳遞給視圖，特別是因爲它們是與您當前使用的特定ORM綁定的類。這確實意味着您將數據框架與視圖類型緊密綁定。

但是，我已經在幾個簡單的MVC應用程序中使用EF實體類型作爲一些強類型視圖的模型 - 它工作正常並且非常簡單。有時候會獲得簡單的勝利，否則你可能會發現自己花費了大量的精力和代碼來複制應用程序中幾乎完全相同的模型類型之間的值，並且實際上你永遠不會離開EF。

Answer 4

即使它們是1：1，也應始終具有視圖模型。有一些實際的原因，而不是我將關注的數據庫層耦合。

作爲視圖類的域，實體框架，nhibernate或linq 2 sql模型的問題是您無法很好地處理上下文驗證。例如，給定用戶等級：

當一個人在網站上籤署了他們獲得了用戶的屏幕，你再：

1. 驗證名稱
2. 驗證電子郵件
3. 驗證密碼已存在

當管理員編輯用戶名時，他們將獲得用戶屏幕，然後：

1. 驗證名稱
2. 驗證電子郵件

現在通過FluentValidation暴露上下文驗證，DataAnnotations屬性，甚至是自定義的isValid（）的業務類的方法和驗證只是姓名和電子郵件的變化。你不能。您需要將不同的上下文表示爲不同的視圖模型，因爲這些模型上的驗證根據屏幕表示而變化。

以前在MVC 1中，您可以通過簡單的方式避免發佈您不想驗證的字段。在MVC 2中，這已經發生了變化，現在模型的每個部分都得到驗證，發佈與否。

---

羅伯特哈維指出了另一個好點。你的用戶Entity Framework如何顯示一個屏幕並驗證雙重密碼匹配？