лучшая практика для того, что находится в ViewModel

Question

Мне интересно, является ли это хорошей идеей или плохой, помещая такие вещи, как Список стран в ViewModel, для привязки к выпадающему списку?Например, на странице регистрации сайта.

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

Не лучше ли поместить его в статический класс где-нибудь и вызывать прямо из View?

Like CommonData.ListCountries ();а затем использовать Lambda для преобразования в список элементов SelectList в представлении Directly?

Answer 1

Как вы уже поняли, существует множество способов достижения вашей цели. В то время как шаблон MVC поощряет определенные организации приложений к организации ваших моделей, представлений и контроллеров, в конечном счете, вопрос предпочтений.

Скотт Аллен обсуждает свое предпочтение иметь дело с раскрывающимися списками ASP.NET MVC в блоге. Скотт использует метод расширения для преобразования перечислимого сложного типа в IEnumerable<SelectListItem> в своей модели. Затем он описывает, что после обратной отправки ASP.NET MVC не будет возвращать IEnumerable<SelectListItem>, который он отправил представлению, а только значение, выбранное пользователем. Затем он предполагает, что использование двух моделей может упростить вещи.

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

• ViewModels содержат данные, которые помогают визуализировать представления. Организовывая мои ViewModels таким образом, я могу разместить всю необходимую информацию, чтобы отобразить конкретное представление в связанную модель. Это избавляет меня от необходимости использовать ViewData для всего, что не является действительно временным.
• FormModels используются для сбора пользовательского ввода. FormModels (почти) никогда не содержат ссылок на другие сложные типы и состоят из примитивов, DateTimes и строк.

В любом случае у меня есть строгое правило: никогда не использовать модель для другого представления . Точное соответствие ваших моделей представлениям, используемым для их визуализации, облегчает написание ваших представлений. Вам не нужно беспокоиться о таких вещах, как статические методы, потому что ваши модели должны переносить данные в связанные представления в форме, которую им легко представить. Такие инструменты, как AutoMapper , могут помочь "сплющить" доменные объекты в модели для отображения.

Для дополнительной проверки чтения: Терминология ASP.NET MVC сбивает меня с толку - почему 'ViewModel'?

Answer 2

Независимо от того, какие данные нужны вашему View, поместите их в ViewModel.

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

Если вы начнете использовать вспомогательные методы, то представление в некотором смысле «возвращается к контроллеру». Методы расширения / помощника подходят для форматирования и т. Д., , но они не должны вызываться через модель .

Не забывайте, у вас также есть ViewData (в основном HttpContext.Current.Items, живет для одного запроса), который представляет собой легкий механизм хранения, который можно использовать для обмена данными между частичными представлениями (например).