Прозрачность передачи данных в представлениях (ASP.NET MVC)

Question

Очень часто мне нужно передавать «сложные» данные в мои представления: разные объекты базы данных, классы и т. Д. И мне надоело создавать десятки таких помощников классов.

class StatsPageViewData 
{ 
    public User User { get; set; } 
    public Something Something { get; set } 
    // blah blah 
} 

Конечно, я не могу просто использовать ViewData ["something"], это просто не так удобно.

Итак, мой вопрос в том, есть ли способ облегчить этот процесс, автоматизировать его каким-то образом?

Answer 1

Модель обзора редко должна быть просто набором классов домена. Прежде всего, помещение классов домена в модель просмотра является большой темой; многие думают, что вы не должны этого делать. Вашему представлению, вероятно, не нужен полный экземпляр пользователя, а только имя. Если вы сохраняете полный экземпляр пользователя в модели представления, он скрывает намерение реальной модели представления, затрудняет повторное использование и т. Д. Вы, возможно, лучше иметь строковое свойство UserName, которое правильно форматирует имя, вместо того, чтобы обращаться к свойствам пользователя в представлении и форматировать его там.

Это теория и никто не имеет имеет, чтобы следить за ней; но хорошо держать в памяти и пытаться добиться.

Во-вторых, ваши модели просмотра не должны быть просто наборами классов домена, поскольку они должны обеспечивать семантику представления - например, атрибуты проверки и дополнительную логику представления. У вас могут быть агрегированные свойства, которые предоставляют данные списков, форматирование и т. Д. Другой пример: модели представлений POST могут иметь методы для преобразования данных необработанной формы в сущности.

Вы должны перенести некоторую логику представления из представлений и/или контроллеров в модели просмотра - форматирование, свойства, которые нужны только представлениям и т. Д. Контроллер не должен преобразовывать коллекцию объектов в коллекцию данных модели просмотра - это должно выглядеть модель просмотра. Просмотр не должен преобразовывать формат пользователя в одно имя и адресную строку - модель просмотра должна.

Поступая таким образом, вы не устанете делать классы класса «вид», потому что они больше не будут глупыми, и ваша работа не будет дампом и/или повторением. Классы модели представления будут столь же важны, как и другие классы в вашем приложении.

Answer 2

Используйте плагин, такой как ReSharper, который поможет вам создать эти вспомогательные классы.

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

Answer 3

Начало с ViewModelBase и расширение, если это необходимо.

Answer 4

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