Подтвердить что ты не робот

ASP.NET MVC - как использовать модели просмотра

Скажем, у меня есть страница, которая позволяет редактировать детали пользователя, поэтому у меня есть ViewModel, как это:

public class UserViewModel {
    public string Username { get; set; }
    public string Password { get; set; }
    public int ManagerId { get; set; }
    public string Category { get; set; }
}

Итак, в моем действии EditUser я могу передать это обратно с помощью привязки модели, а затем я смогу сопоставить это с моделью домена:

public ActionResult EditUser(UserViewModel user) {
    ...

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

Итак, у меня есть другая модель представления:

public class ViewUserViewModel {
    public UserViewModel EditingUser { get; set; }
    public IEnumerable<SelectListItem> Managers { get; set; }
    public IEnumerable<SelectListItem> Categories { get; set; }
    public IEnumerable<SelectListItem> AllUsers { get; set; }
}

Это правильный способ сделать это? Они оба видят модели? Если да, существует ли соглашение об именах, которое я должен использовать, чтобы я мог различать виртуальные машины, похожие на модели и виртуальные машины, которые содержат только данные для страницы?

У меня все получилось?

4b9b3361

ОТВЕТЫ

Ответ 1

Как это сделать в ярлыке:

  • Создайте отдельный класс ViewModel для каждой формы на странице, затем я создаю эти классы с PartialViews как @{Html.RenderPartial("PartialName", Model.PartialModel);}.
  • Если на странице есть такие вещи, как html metas, я делаю отдельный класс для метафайлов и помещаю его в раздел на странице.
  • Случаи для отдыха, такие как "я должен помещать это в отдельный класс?" это ваше мнение.

Так, например, у вас есть страница с какой-то регистрационной панелью или всплывающим окном.

public class SomePageViewModel
{
    public RegisterBarVM Register { get; set; }
    public LoginBarVM LoginBar { get; set; }

    public MetasVM Metas { get; set; }
    public string MaybePageTitle { get; set;}
    public string MaybePageContent { get; set;}

    [HiddenInput(DisplayValue = false)]
    public int IdIfNeeded { get; set; }

    public IEnumerable<SelectListItem> SomeItems {get; set;}
    public string PickedItemId { get;set; }
}

public class RegisterBarVM
{
    public string RegisterUsername {get;set;}
    public string RegisterPassword {get;set;}
    //...
}

public class LoginBarVM
{
    public string LoginUserame {get;set;}
    public string LoginPassword {get;set;}
    //...
}

//cshtml
@model yourClassesNamespace.SomePageViewModel
@{
    Html.RenderPartial("LoginBar", Model.LoginBar); //form inside
    Html.RenderPartial("RegisterBar", Model.RegisterBar); //form inside

    using(Html.BeginForm())
    {
        @Html.EditorFor(m => m.IdIfNeeded)
        @Hmtl.EditorFor(m => m.MaybePageTitle)
        @Hmtl.EditorFor(m => m.MaybePageContent)

        @Hmtl.DropDownListFor(m => m.PickedItemId, new SelectList(Model.SomeItems))

        <input type="submit" value="Update" />
    }
}

@section Metas {
    @{Html.RenderPartial("Meatas", Model.Metas}
}

О шаблонах редактора Блог Брэда Уилсонса и просто Google или найдите ресурсы стеков о шаблонах отображения/редактора и HtmlHelpers. Все они очень полезны для создания согласованных веб-сайтов.

Ответ 2

"Модель просмотра" - это всего лишь шаблон. Там нет ничего волшебного в названии, но, как правило, любой класс, передаваемый в представление (будь то просто для отображения данных или для целей представления формы), называется "моделью просмотра" и имеет имя типа FooViewModel или FooVM, чтобы указать, что это часть этого шаблона модели представления.

Я не хочу слишком философски относиться к вам, но я думаю, что небольшая ссылка на образцы в игре будет полезна. ASP.NET MVC достаточно явно поощряет архитектурную модель MVC (Model-View-Controller). В MVC модель является контейнером для всей бизнес-логики приложения. Контроллер отвечает за обработку запроса, выборку модели, визуализацию представления с этой моделью и возвращение ответа. Это похоже на большую ответственность, но на самом деле структура обрабатывает большую часть этого за кулисами, поэтому контроллеры обычно (и должны быть) очень легки на коде. Они несут ответственность за минимальный объем функциональности, чтобы подключить все. Наконец, представление отвечает за создание слоя пользовательского интерфейса, который позволяет пользователю взаимодействовать с данными в модели. Он не несет ответственности за сами данные и не должен быть (ViewData/ViewBag здесь является довольно большим нарушением, по крайней мере, так же, как и тем, как он используется разработчиками на практике).

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

Здесь представлены модели представлений. MVVM (модель-представление-модель), несколько параллельный шаблон для MVC, распознает присущие проблемы в подходе с одной моделью к правилу-все-все. Здесь я не буду вдаваться в подробности, потому что MVC не использует этот шаблон. Однако большинство разработчиков ASP.NET MVC кооптировали модель просмотра MVVM. То, что вы по существу в конечном итоге, - это объект с поддержкой базы данных (традиционная модель), а затем обычно много разных моделей представлений, которые представляют эту сущность в разных состояниях. Это позволяет вашей модели содержать бизнес-логику, которая имеет отношение к сохранению, в то время как модель представления содержат бизнес-логику, относящуюся к отображению, созданию и обновлению этой модели.

Я немного ушел, но длинный и короткий - то, что вы делаете, вполне приемлемо. На самом деле это хорошая практика. Создайте столько моделей просмотра, сколько требуется вашему приложению, и используйте их для фактического хранения данных и бизнес-логики, необходимых для ваших просмотров. (Это включает в себя такие вещи, как SelectList s. Ни ваш контроллер, ни представление не должны знать, как создать SelectList для выпадающего списка.)

Ответ 3

Я лично предпочитаю помещать всю информацию, необходимую для отображения страницы в ViewModel, поскольку это цель ViewModel - предоставить все данные для представления. Таким образом, my UserViewModel будет содержать свойства для Managers, Categories и AllUsers, и контроллер будет заполнять эти коллекции до передачи ViewModel в представление.

Это по сути то, что вы сделали - он просто удаляет лишнюю ViewModel из уравнения.

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