ViewModel для модели с большим количеством свойств?

Question

Я планирую создать приложение Asp.Net MVC, которое содержит страницы редактирования/создания для большой модели с отношением «многие ко многим» с другими моделями. Я нашел Saving Many to Many relationship data on MVC Create view и планирую использовать его.

В примере на странице создания используется следующая ViewModel.

public class UserProfileViewModel 
{ 
    public int UserProfileID { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<AssignedCourseData> Courses { get; set; } 
} 

И UserProfile модель имеет только два свойства, так что ViewModel просто дублирует все свойства.

public class UserProfile 
{ 
    public UserProfile() 
    { 
     Courses = new List<Course>(); 
    } 
    public int UserProfileID { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<Course> Courses { get; set; } 
} 

Однако, в моем случае, там будет много свойств (с аннотациями данных), скажем, 50 свойств. Должен ли ViewModel дублировать все эти свойства (с аннотациями данных тоже)? (выглядит уродливо?) Или есть лучший способ?

Update Это хорошая практика, чтобы определить, как ViewModel

public class UserProfileViewModel 
{ 
    public UserProfile UserProfile { get; set; } 
    .... // Other properties needed by the view. 
} 

Один недостаток этого способа является его разоблачить все свойства в модели даже это не требуется в представлении.

Answer 1

Взято из: This excellent explanation of ViewBag, ViewData and TempData

тип данных, который подходит ViewModels хорошо выглядит следующим образом:

• Master-Detail данные
• Большие наборы данных
• Комплексные реляционные данные
• Отчетные и агрегированные данные
• Панели мониторинга
• данных из разнородных источников

Таким образом, в общем, да ViewModel является то, что использовать, когда представление требует много сложности, это соответствует вашим потребностям. Что касается использования и заполнения каждого свойства, которое должно определяться тем, что требуется конкретному виду. ViewModels - это не обязательно одно-единственное представление модели/сущности. Это должно быть продиктовано вашими требованиями к представлению, например. UserCourseViewModel может агрегировать объекты UserProfile и Course, но не обязательно все оба их свойства, если, конечно, все свойства не требуются для представления.

Rachels Резюме:

Объекты ViewData и ViewBag дают вам способы доступа этим дополнительным элементам данных, которые идут вместе с вашей моделью, однако для более сложных данных, вы можете перейти к ViewModel. С другой стороны, TempData специально предназначен для работы с данными по переадресации HTTP, поэтому помните, что будьте осторожны при использовании TempData.

Answer 2

Вещь с View Model очень проста: модель просмотра должна состоять только из данных, необходимых для представления. То есть, дизайн модели представления управляется (статическим) представлением. Статический, потому что вы можете обновлять части представления через ajax в браузере, поэтому для вашей модели нет смысла содержать эту информацию (за исключением случаев, когда это необходимо в качестве значений инициализации для javascript).

Как хранятся данные или как они используются бизнес-уровнем (если таковые имеются) не относится к модели представления.

Обновлено

Чистейший и безопасный способ заключается в определении модели представлений со свойствами, которые необходимо (вы можете копировать вставить их из другой модели это нормально в этом случае), а затем использовать Automapper для отображения бизнес объект к модели представления. Таким образом, вы можете развить обе модели по-разному. Лично, очень редко моя модель взгляда идентична бизнес-модели, они очень похожи, но там крошечные различия, которые усложняют ситуацию.

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