Есть ли лучший способ использовать несколько моделей, чем через ViewModels в ASP.NET MVC?

Question

Я недавно работаю с ASP.NET MVC 2, и одним из примеров, которым я следую , является официальный магазин ASP.NET MVC Music Store на codeplex.

В примере проекта у них есть такой сценарий: есть три модели: Albums, Artists, Genres.

Что заставляет меня сомневаться в том, как они относятся к своим представлениям, например, когда они хотят отредактировать альбом, необходимо иметь список всех исполнителей и жанров из базы данных, поэтому они создают ViewModel с именем StoreManagerViewModel :

public class StoreManagerViewModel{
  public Album Album{get;set;}
  public List<Artists> Artists{get;set;}
  public List<Genre> Genres{get;set;}
}

Эта ViewModel передается в представление и позволяет использовать intellisense и просматривать несколько моделей в представлении.

Этот метод, кажется, заставил бы меня иметь дополнительный класс для почти каждого отношения в моей модели: Если у меня есть класс Discography, и я хочу связать Artists с Discography, мне придется создать другую ViewModel, подобную описанной выше.

Однако мне не нравятся два свойства внутри метода Album:

public List<Artists> Artists{get;set;}
public List<Genre> Genres{get;set;}

Есть ли лучший способ сделать это, кроме ViewModels? Есть ли более чистый путь?

Answer 1

Все остальные ответы на этой странице до сих пор оставили одну важную концепцию модели представления: она отделяет слой данных от уровня представления и устраняет возможность для представления создавать запросы, которые могут разрушить вашу базу данных.,Дело не только в intellisense и отправке нескольких моделей в представление, хотя это и другие плюсы.

Скажем, например, что вы хотите загрузить на свой сайт 100 лучших пользователей с переполнением стека, чье имя начинается с myNamePrefix.Затем для каждого пользователя вы хотите отобразить список тегов, для которых у них более 10 голосов.Вы могли бы просто передать список Users вашему представлению, а затем вызвать свойство .Tags, которое затем совершит поездку в оба конца в БД для каждого из ваших 100 пользователей.Это может быть хорошо, если БД находится на той же машине, что и веб-сервер, и вы получаете только несколько обращений в день.Но допустим, вы пытаетесь обработать эти данные для различных значений myNamePrefix каждую секунду.Возможно, вы могли бы найти некоторые творческие способы кеширования результатов, но по большей части лучше заполнить модель представления всеми необходимыми данными (в данном случае с помощью одного запроса), и просто сделать так, чтобы представление выкладывало результаты.Помните, что задача представления - отображать данные, а не извлекать их.

Answer 2

Причина, по которой они решили создать отдельную ViewModel вместо использования уже созданной модели, такой как Albums, Artist или Genre, заключается в том, что требовались все 3.Если требуется только один, такой как Albums, было бы хорошо передать только Album или IList<Album> в зависимости от использования.

В ASP.NET MVC моделью может быть любой объект в системечто вы хотите отправить на просмотр.Даже string, int и любой другой базовый тип.

В ASP.NET MVC 3 вы также можете использовать ключевое слово dynamic в качестве ViewModel, чтобы вам даже не приходилось указывать тип.Однако вам, вероятно, следует избегать этого, пока это не станет последним средством, потому что всегда лучше иметь статически типизированную ViewModel.

Наконец, вам вообще не нужно указывать модель, вы можете установить и извлечьинформация из словаря ViewModel.Но этого, вероятно, следует избегать для чего-то более сложного, чем самая простая информация, потому что, как и dynamic, она не имеет статической типизации.

Answer 3

Есть другой способ. Вы можете использовать ChildActions.

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

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

Это просто другой способ. Что лучше, зависит от проблемы, которую вы пытаетесь решить.

Answer 4

когда вы используете Linq to SQL, в каждой модели будут загружены дочерние и родительские объекты (когда ваша БД исправна).Таким образом, в этом случае исходная модель очень часто используется в режиме редактирования или в режиме создания.потому что ваша модель будет создана для вас.

ViewModels - это чистый путь.

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

Answer 5

ViewModel существует по двум причинам:

1. Поддержка Intellisense.
2. Экземпляры, в которых простой модели просто недостаточно для просмотра.

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

В некоторых случаях вынужно только отправить один вид на вашу модель.Используйте его там, где это имеет смысл, и когда вам нужно только отправить одну модель в представление (и вас не интересует intellisense), тогда отправьте только одну модель в это представление.