Привязка модели к контроллеру при отправке формы - зачем использовать модель представления вместо класса из модели домена?

Question

Я по-прежнему новичок в ASP.NET MVC 3. Я столкнулся с моделями взглядов и их использованием для передачи данных с контроллера на представление. В моем недавнем question on model binding два эксперта предположили, что я должен также использовать модели представления для привязки к модели.

Это то, с чем я не сталкивался раньше. Но оба парня заверили меня, что это лучшая практика. Может кто-то может пролить свет на причины, по которым модели просмотра более подходят для привязки к модели?

Вот пример ситуации: У меня есть простой класс в моей модели домена.

public class TestParent 
{ 
    public int TestParentID { get; set; } 
    public string Name { get; set; } 
    public string Comment { get; set; } 
} 

И это мой контроллер:

public class TestController : Controller 
{ 
    private EFDbTestParentRepository testParentRepository = new EFDbTestParentRepository(); 
    private EFDbTestChildRepository testChildRepository = new EFDbTestChildRepository(); 

    public ActionResult ListParents() 
    { 
     return View(testParentRepository.TestParents); 
    } 

    public ViewResult EditParent(int testParentID) 
    { 
     return View(testParentRepository.TestParents.First(tp => tp.TestParentID == testParentID)); 
    } 

    [HttpPost] 
    public ActionResult EditParent(TestParent testParent) 
    { 
     if (ModelState.IsValid) 
     { 
      testParentRepository.SaveTestParent(testParent); 
      TempData["message"] = string.Format("Changes to test parents have been saved: {0} (ID = {1})", 
                 testParent.Name, 
                 testParent.TestParentID); 
      return RedirectToAction("ListParents"); 
     } 
     // something wrong with the data values 
     return View(testParent); 
    } 
} 

Таким образом, в третьем способе действий, который вызывается, когда POST HTTP прибывает я TestParent для связывания модели. Это было довольно удобно, потому что страница браузера, которая генерирует запрос HTTP POST, содержит поля ввода для всех свойств TestParent. И я на самом деле думал, что так работают шаблоны, которые Visual Studio предоставляет для операций CRUD.

Однако рекомендация, которую я получил, заключалась в том, что подпись третьего метода действия должна читать public ActionResult EditParent(TestParentViewModel viewModel).

Answer 1

Это звучит привлекательно, но по мере того как ваши модели и действия вида становятся все более сложными, вы начинаете видеть значение использования ViewModels для (большинства) всего, особенно для ввода сценариев.

• Корпус 1 - Большинство веб-фреймворков подвержены перегрузке. Если вы привязываетесь прямо к своей модели домена, очень возможно перепечатать данные и злонамеренно изменить что-то, не принадлежащее пользователю. Я считаю, что более чистое связывание с моделью представления ввода, чем длинными строковыми списками белых списков или черных списков, хотя есть и другие интересные способы привязки к интерфейсу.

• Случай 2 - Как ваш вклад растет в сложностях, вы будете работать в то время, когда вам нужно представить и проверять поля не непосредственно в модели предметной области («Я согласен» флажки и т.д.)

• Case 3 - Больше личной вещи, но я нахожу привязку модели к объектам реляционной области, чтобы быть гигантской болью время от времени. Легче связать их в AutoMapper, чем с модельным списком MVC для сложных графиков объектов. Помощники html MVC также работают более плавно против примитивных типов, чем глубокие реляционные модели.

Недостатки использования ViewModels в том, что он не очень СУХОЙ.

Таким образом, мораль этой истории привязана к моделям доменов, может быть жизнеспособным решением для простых вещей, но по мере увеличения сложности становится легче иметь отдельную модель представления, а затем отображать между ними.