ASP.NET MVC: вложение ViewModels друг в друга, антипаттерн или нет?

Question

У меня есть проект, в котором ViewModels вложены друг в друга так, что они по сути являются строковой репликацией иерархии домена.Например, если наш домен имеет следующие отношения:

В организации имеется от 1 до нескольких сред

В среде имеется от 1 до нескольких машин

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

Теперь, как бы мне ни хотелось спуститься сверху и осудить эту практику, я не смог найти много информации по этому поводу.Кто-нибудь может указать мне более подробную информацию об установившейся практике?Анекдоты поделиться?

(Мой собственный уклон заключается в том, что эти ViewModel не должны быть вложены друг в друга таким образом, и ViewModels должны на самом деле соответствовать представлениям, а не объектам домена. Я нахожу это довольно запутанным с некоторыми проблемами сопровождения.Но я хотел бы знать, что другие думают или испытали.)

Я приложил этот вопрос для справки, но он описывает вложение объекта домена внутри модели представления, а не модели представления внутри друг друга.

Answer 1

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

Не думайте, что «модель представления должна соответствовать представлению»Подумайте об этом иначе: «представление - это html-представление данных модели представления».

ViewModel - ужасный термин, потому что это не представление и не модель, а представление ресурса.

Если я сделаю:

`GET /User/1`

Я ожидаю назад некоторые данные, представляющие пользователя 1. Если это в формате HTML, потому что я послал

`Accept: text/html`

, то пусть будет так.Подумайте, как ваша модель представления будет выглядеть как XML или JSON.

Старайтесь избегать вложения моделей представления при создании цепочки зависимостей, просто дублируйте свойства, вы не нарушаете DRY на самом деле

Answer 2

Я все еще хочу знать преимущества ... и недостатки. Это быстрее - или проще для чтения? Если у вас есть представление, которое требует рендеринга всей информации, не проще ли стремиться получить все для отображения в одной БД Получить вместо нескольких ленивых болтливых соединений?

В одном представлении пользователь не хотел бы видеть «сводку организации», которая включает все связанные «среды» и «машины». Количество потенциально вложенных элементов, если ничего больше. (Не информация об окружающей среде и машине - они заслуживают разных мнений)

Кажется, что есть склонность к видам здания, чтобы выполнить одну обязанность (Просмотр машины (показывает только информацию о машине) -> Просмотр деталей машины (только показывает детали машины)) Это было бы достаточно просто, чтобы это произошло, но наступает момент, когда представления не обладают богатым набором функций, поскольку информации просто слишком мало.

Answer 3

ViewModels должны быть связаны с концепциями пользовательского интерфейса, а не обязательно с концепциями домена.Итак, в вашем примере я могу представить один экран, который показывает детали организации и список сред;щелкнув Окружение, вы попадете на экран сведений, на котором отобразится список машин;и щелкнув один из них, вы попадете в представление сведений о машине.

В этом примере есть 2 разных представления среды или компьютера, сводное представление, занимающее строку в списке, и представление сведений,занимает лучшую часть экрана - каждый из которых должен иметь свою собственную ViewModel.Я бы, вероятно, создал для этого ViewModels так:

OrganizationDetailsViewModel
----List of EnvironmentSummaryViewModels


EnvironmentDetailsViewModel
----List of MachineSummaryViewModels

MachineDetailsViewModel

В зависимости от того, насколько сложен ваш пользовательский интерфейс, вложение может стать глубже.Давайте представим, что у вас был маленький графический индикатор состояния для среды, которая смотрела на состояние и отображала определенный цвет.Вы можете создать отдельную EnvironmentStatusViewModel, которая затем будет вложена в EnvironmentSummaryViewModel и, возможно, также вложена в EnvironmentDetailsViewModel.

Answer 4

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

Я стараюсь держать мой как можно более ровным, хотя обычно встречается 1 уровень вложенности, удовлетворяющий большинству сценариев, которые я обнаружил.

Связанный вопрос, на который я ответил здесь: Две модели в одном представлении в ASP MVC 3

Answer 5

Мы следовали статье Джоша Смита Упрощение WPF TreeView с помощью шаблона ViewModel в прошлом.Хотя это с WPF вместо MVC, я считаю, что концепция все еще применима.Я обнаружил, что это разумный механизм для разделения проблем отображения в каждом контексте и обеспечения большей гибкости при повторном использовании.

HTH