Что такое ViewModel в MVC?

Я новичок в ASP.NET MVC. У меня есть проблема в понимании цели ViewModel.

Что такое ViewModel и зачем нам нужен ViewModel для приложения ASP.NET MVC?

Лучше, если у меня будет простой пример.

ОТВЕТЫ

Ответ 1

view model представляет данные, которые вы хотите отобразить на вашем представлении/странице, независимо от того, используются ли они для статического текста или для входных значений (таких как текстовые поля и раскрывающиеся списки), которые могут быть добавлены в базу данных (или отредактированы). Это нечто отличное от вашего domain model. Это модель для представления.

Допустим, у вас есть класс Employee, представляющий модель домена вашего сотрудника, и он содержит следующие свойства (уникальный идентификатор, имя, фамилия и дата создания):

public class Employee : IEntity
{
     public int Id { get; set; }

     public string FirstName { get; set; }

     public string LastName { get; set; }

     public DateTime DateCreated { get; set; }
}

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

public class CreateEmployeeViewModel
{
     public string FirstName { get; set; }

     public string LastName { get; set; }
}

Как вы можете видеть, он содержит только два свойства. Эти два свойства также находятся в модели домена сотрудника. Почему это вы можете спросить? Id может быть не установлено из представления, оно может быть автоматически сгенерировано таблицей Employee. И DateCreated также может быть установлен в хранимой процедуре или на уровне обслуживания вашего приложения. Поэтому Id и DateCreated не нужны в модели представления. Возможно, вы захотите отобразить эти два свойства при просмотре сведений о сотруднике (уже зарегистрированный сотрудник) в виде статического текста.

При загрузке представления/страницы метод create action в контроллере сотрудника создаст экземпляр этой модели представления, заполнит все поля, если необходимо, а затем передаст эту модель представления представлению/странице:

public class EmployeeController : Controller
{
     private readonly IEmployeeService employeeService;

     public EmployeeController(IEmployeeService employeeService)
     {
          this.employeeService = employeeService;
     }

     public ActionResult Create()
     {
          CreateEmployeeViewModel model = new CreateEmployeeViewModel();

          return View(model);
     }

     public ActionResult Create(CreateEmployeeViewModel model)
     {
          // Do what ever needs to be done before adding the employee to the database
     }
}

Ваш вид/страница может выглядеть следующим образом (при условии, что вы используете ASP.NET MVC и Razor механизм просмотра):

@model MyProject.Web.ViewModels.CreateEmployeeViewModel

<table>
     <tr>
          <td><b>First Name:</b></td>
          <td>@Html.TextBoxFor(m => m.FirstName, new { maxlength = "50", size = "50" })
              @Html.ValidationMessageFor(m => m.FirstName)
          </td>
     </tr>
     <tr>
          <td><b>Last Name:</b></td>
          <td>@Html.TextBoxFor(m => m.LastName, new { maxlength = "50", size = "50" })
              @Html.ValidationMessageFor(m => m.LastName)
          </td>
     </tr>
</table>

Проверка будет выполняться только на FirstName и LastName. Используя FluentValidation, вы можете иметь такую проверку:

public class CreateEmployeeViewModelValidator : AbstractValidator<CreateEmployeeViewModel>
{
     public CreateEmployeeViewModelValidator()
     {
          RuleFor(m => m.FirstName)
               .NotEmpty()
               .WithMessage("First name required")
               .Length(1, 50)
               .WithMessage("First name must not be greater than 50 characters");

          RuleFor(m => m.LastName)
               .NotEmpty()
               .WithMessage("Last name required")
               .Length(1, 50)
               .WithMessage("Last name must not be greater than 50 characters");
     }
}

А с аннотациями данных это может выглядеть так:

public class CreateEmployeeViewModel : ViewModelBase
{
    [Display(Name = "First Name")]
    [Required(ErrorMessage = "First name required")]
    public string FirstName { get; set; }

    [Display(Name = "Last Name")]
    [Required(ErrorMessage = "Last name required")]
    public string LastName { get; set; }
}

Важно помнить, что модель представления представляет собой только те данные, которые вы хотите использовать, и ничего больше. Вы можете представить весь ненужный код и проверку, если у вас есть модель домена с 30 свойствами, и вы хотите обновить только одно значение. При таком сценарии у вас будет только одно значение/свойство в модели представления, а не все свойства, которые находятся в объекте домена.

Модель представления может иметь не только данные из одной таблицы базы данных. Он может объединять данные из другой таблицы. Возьмите мой пример выше о добавлении новой записи сотрудника. Помимо добавления только имени и фамилии, вы также можете добавить отдел сотрудника. Этот список отделов будет взят из вашей таблицы Departments. Итак, теперь у вас есть данные из таблиц Employees и Departments в одной модели представления. Затем вам нужно будет добавить следующие два свойства в модель представления и заполнить ее данными:

public int DepartmentId { get; set; }

public IEnumerable<Department> Departments { get; set; }

При редактировании данных о сотруднике (сотрудник, который уже был добавлен в базу данных) он не сильно отличается от моего примера выше. Создайте модель вида, назовите ее, например, EditEmployeeViewModel. Только данные, которые вы хотите редактировать в этой модели представления, например, имя и фамилия. Отредактируйте данные и нажмите кнопку отправки. Я бы не стал слишком беспокоиться о поле Id, потому что значение Id, вероятно, будет в URL, например:

http://www.yourwebsite.com/Employee/Edit/3

Возьмите этот Id и передайте его на уровень хранилища вместе с вашими значениями имени и фамилии.

При удалении записи я обычно иду по тому же пути, что и в модели редактирования. У меня также будет URL, например:

http://www.yourwebsite.com/Employee/Delete/3

Когда представление загружается впервые, я получаю данные о сотрудниках из базы данных, используя Id из 3. Затем я просто отображаю статический текст на своем представлении/странице, чтобы пользователь мог видеть, какой сотрудник удаляется. Когда пользователь нажимает кнопку "Удалить", я просто использую значение Id, равное 3, и передаю его слою своего хранилища. Вам нужен только Id, чтобы удалить запись из таблицы.

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

Я надеюсь, что это прояснит любую вашу путаницу с моделями представления и моделями доменов.

Ответ 2

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

public class LoginPageVM
{
    [Required(ErrorMessage = "Are you really trying to login without entering username?")]
    [DisplayName("Username/e-mail")]
    public string UserName { get; set; }
    [Required(ErrorMessage = "Please enter password:)")]
    [DisplayName("Password")]
    public string Password { get; set; }
    [DisplayName("Stay logged in when browser is closed")]
    public bool RememberMe { get; set; }
}

Используя эту модель представления, вы можете определить представление (механизм просмотра Razor):

@model CamelTrap.Models.ViewModels.LoginPageVM

@using (Html.BeginForm()) {
    @Html.EditorFor(m => m);
    <input type="submit" value="Save" class="submit" />
}

И действия:

[HttpGet]
public ActionResult LoginPage()
{
    return View();
}

[HttpPost]
public ActionResult LoginPage(LoginPageVM model)
{
    ...code to login user to application...
    return View(model);
}

Что производит этот результат (экран берется после отправки формы с сообщениями проверки):

Как вы можете видеть, модель представления имеет много ролей:

  • Просмотр документов моделей с представлением, состоящим только из полей, представленных в представлении.
  • Просмотр моделей может содержать специальные правила проверки с использованием аннотаций данных или IDataErrorInfo.
  • Модель просмотра определяет, как должно выглядеть представление (для помощников LabelFor, EditorFor, DisplayFor).
  • Просмотр моделей может объединять значения из разных объектов базы данных.
  • Вы можете легко указывать шаблоны отображения для моделей просмотра и повторно использовать их во многих местах с помощью помощников DisplayFor или EditorFor.

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

public class UserVM {
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public bool IsAdministrator { get; set; }
    public string MothersName { get; set; }
}

индексирование:

var user = db.userRepository.GetUser(id);

var model = new UserVM() {
   ID = user.ID,
   FirstName = user.FirstName,
   LastName = user.LastName,
   IsAdministrator = user.Proviledges.IsAdministrator,
   MothersName = user.Mother.FirstName + " " + user.Mother.LastName
}

Ответ 3

Изменить: я обновил этот ответ в своем блоге:

http://www.samwheat.com/Post/The-function-of-ViewModels-in-MVC-web-development

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

Подводя итог и непосредственно отвечая на заданный вопрос:

Вообще говоря, модель представления - это объект, который содержит все свойства и методы, необходимые для визуализации представления. Просмотр свойств модели часто связан с объектами данных, такими как клиенты и заказы, и кроме того, они также содержат свойства, относящиеся к самой странице или приложению, такие как имя пользователя, имя приложения и т.д. Модели просмотра предоставляют удобный объект для перехода к механизму рендеринга для создайте страницу html. Одной из многих причин использования модели представления является то, что модели представления предоставляют способ unit test некоторым задачам представления, таким как обработка ввода пользователя, проверка данных, извлечение данных для отображения и т.д.

Вот сравнение моделей Entity (модели a.ka. DTO a.ka.), моделей презентаций и моделей просмотра.

Объекты передачи данных a.k.a "Модель"

Объект передачи данных (DTO) - это класс со свойствами, которые соответствуют схеме таблицы в базе данных. DTO называются для общего использования для передачи данных в хранилище данных и из хранилища данных.
Характеристики DTO:

• Являются ли бизнес-объекты - их определение зависит от данных приложения.

• Обычно содержат только свойства - нет кода.

• В первую очередь используется для транспортировки данных в базу данных и из нее.

• Свойства точно или близко соответствуют полям в конкретной таблице в хранилище данных.

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

Вот два примера того, как могут выглядеть DTO:

public class Customer
{
    public int ID { get; set; }
    public string CustomerName { get; set; }
}


public class Order
{
    public int ID { get; set; }
    public int CustomerID { get; set; }
    public DateTime OrderDate { get; set; }
    public Decimal OrderAmount { get; set; }
}

Модели презентаций

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

Характеристики моделей презентаций:

• Являются ли бизнес-объекты - их определение зависит от данных приложения.

• Содержит в основном свойства. Обычно код ограничивается форматированием данных или преобразованием в DTO или из него. Модели презентации не должны содержать бизнес-логику.

• Часто представляют денормализованный вид данных. То есть, они часто объединяют свойства нескольких DTO.

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

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

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

Пример модели представления:

public class PresentationOrder
{
    public int OrderID { get; set; }
    public DateTime OrderDate { get; set; }
    public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
    public string CustomerName { get; set; }
    public Decimal OrderAmount { get; set; }
    public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}

Просмотр моделей

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

Характеристики моделей просмотра:

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

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

• Содержит код приложения. Модели просмотра обычно содержат методы, которые вызывают во время рендеринга, и когда пользователь взаимодействует со страницей. Этот код обычно относится к обработке событий, анимации, видимости элементов управления, стилю и т.д.

• Содержит код, который вызывает бизнес-службы для извлечения данных или отправки их на сервер базы данных. Этот код часто ошибочно помещается в контроллер. Вызов бизнес-сервисов с контроллера обычно ограничивает полезность модели представления для модульного тестирования. Чтобы быть ясными, сами модели просмотра не должны содержать бизнес-логику, но должны обращаться к службам, которые содержат бизнес-логику.

• Часто содержат свойства, которые представляют собой другие модели просмотра для других страниц или экранов.

• Записываются "на страницу" или "на экран". Уникальная модель просмотра обычно записывается для каждой страницы или экрана в приложении.

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

Просмотр состава модели

Как указывалось ранее, модели представления представляют собой составные объекты, поскольку они объединяют свойства приложения и свойства бизнес-данных на одном объекте. Примерами обычно используемых свойств приложения, которые используются в моделях просмотра, являются:

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

• Свойства, используемые для форматирования, отображения, стилизации или анимации элементов управления.

• Свойства, используемые для связывания данных, такие как объекты списка и свойства, которые содержат промежуточные данные, которые вводятся пользователем.

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

Предположим, что мы пишем веб-приложение. Одним из требований дизайна приложения является то, что заголовок страницы, имя пользователя и имя приложения должны отображаться на каждой странице. Если мы хотим создать страницу для отображения объекта порядка представления, мы можем изменить модель представления следующим образом:

public class PresentationOrder
{
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }
    public int OrderID { get; set; }
    public DateTime OrderDate { get; set; }
    public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
    public string CustomerName { get; set; }
    public Decimal OrderAmount { get; set; }
    public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}

Эта конструкция может работать... но что, если мы хотим создать страницу, на которой будет отображаться список заказов? Свойства PageTitle, UserName и ApplicationName будут повторяться и стать неудобными для работы. Кроме того, что, если мы хотим определить некоторую логику уровня страницы в конструкторе класса? Мы больше не можем этого делать, если мы создадим экземпляр для каждого порядка, который будет отображаться.

Состав над наследованием

Здесь мы можем переопределить модель представления заказов таким образом, чтобы она стала реальной моделью представления и будет полезна для отображения одного объекта PresentationOrder или коллекции объектов PresentationOrder:

public class PresentationOrderVM
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business properties
    public PresentationOrder Order { get; set; }
}


public class PresentationOrderVM
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business properties
    public List<PresentationOrder> Orders { get; set; }
}

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

Мы можем сделать наш проект еще одним шагом и создать класс модели базового представления, который может использоваться не только для PresentationOrders, но и для любого другого класса:

public class BaseViewModel
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }
}

Теперь мы можем упростить наш PresentationOrderVM следующим образом:

public class PresentationOrderVM : BaseViewModel
{
    // Business properties
    public PresentationOrder Order { get; set; }
}

public class PresentationOrderVM : BaseViewModel
{
    // Business properties
    public List<PresentationOrder> Orders { get; set; }
}

Мы можем сделать наш BaseViewModel еще более пригодным для повторного использования, сделав его общим:

public class BaseViewModel<T>
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business property
    public T BusinessObject { get; set; }
}

Теперь наши реализации легки:

public class PresentationOrderVM : BaseViewModel<PresentationOrder>
{
    // done!
}

public class PresentationOrderVM : BaseViewModel<List<PresentationOrder>>
{
    // done!
}

public class PresentationOrderVM : BaseViewModel<PresentationOrder>
{
    // done!
}

public class PresentationOrderVM : BaseViewModel<List<PresentationOrder>>
{
    // done!
}

Ответ 4

Если у вас есть свойства, специфичные для представления, и не связанные с хранилищем DB/Service/Data, рекомендуется использовать ViewModels. Скажем, вы хотите оставить флажок, выбранный на основе поля БД (или двух), но само поле БД не является логическим. Хотя можно создать эти свойства в самой модели и сохранить ее скрытой от привязки к данным, вы можете не захотеть загромождать модель в зависимости от количества таких полей и транзакций.

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

Ответ 5

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

Если модель похожа на базу данных Таблица, то ViewModel сродни базе данных Вид. Обычно представление либо возвращает небольшие объемы данных из одной таблицы, или, сложные наборы данных из нескольких таблиц (объединения).

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

Ответ 6

MVC не имеет viewmodel: он имеет модель, представление и контроллер. Модель просмотра является частью MVVM (Model-View-Viewmodel). MVVM получен из модели представления и популяризируется в WPF. Также должна быть модель в MVVM, но большинство людей полностью игнорируют точку этого шаблона, и у них будет только представление и viewmodel. Модель в MVC похожа на модель в MVVM.

В MVC процесс разбивается на 3 разные обязанности:

  • View отвечает за представление данных пользователю
  • Контроллер отвечает за поток страниц
  • Модель отвечает за бизнес-логику

MVC не очень подходит для веб-приложений. Это шаблон, созданный Smalltalk для создания настольных приложений. Веб-среда ведет себя совершенно иначе. Не имеет смысла копировать 40-летнюю концепцию из разработки рабочего стола и вставлять ее в веб-среду. Однако многие считают, что это нормально, потому что их приложение компилирует и возвращает правильные значения. То есть, на мой взгляд, недостаточно, чтобы объявить определенный выбор дизайна как хорошо.

Примером модели в веб-приложении может быть:

public class LoginModel
{
    private readonly AuthenticationService authentication;

    public LoginModel(AuthenticationService authentication)
    {
        this.authentication = authentication;
    }

    public bool Login()
    {
        return authentication.Login(Username, Password);
    }

    public string Username { get; set; }
    public string Password { get; set; }
}

Контроллер может использовать его следующим образом:

public class LoginController
{
    [HttpPost]
    public ActionResult Login(LoginModel model)
    {
        bool success = model.Login();

        if (success)
        {
            return new RedirectResult("/dashboard");
        }
        else
        {
            TempData["message"] = "Invalid username and/or password";
            return new RedirectResult("/login");
        }
    }
}

Ваши методы управления и ваши модели будут небольшими, легко проверяемыми и точными.

Ответ 7

Просмотр модели a - это простой класс, который может содержать более одного свойства класса. Мы используем его для наследования всех необходимых свойств, например. У меня есть два класса: Student and Subject

Public class Student
{
public int Id {get; set;}
public string Name {get; set;}
}  
Public class Subject
{
public int SubjectID {get; set;}
public string SubjectName {get; set;}
}

Теперь мы хотим отобразить записи студенческого имени и имени субъекта в представлении (в MVC), но невозможно добавить более одного класса, например:

 @model ProjectName.Model.Student  
 @model ProjectName.Model.Subject

приведенный выше код выдает ошибку...

Теперь мы создаем один класс и можем дать ему любое имя, но этот формат "XyzViewModel" упростит его понимание. Это концепция наследования. Теперь мы создаем третий класс со следующим именем:

public class StudentViewModel:Subject
{
public int ID {get; set;}
public string Name {get; set;}
}

Теперь мы используем эту ViewModel в представлении

@model ProjectName.Model.StudentViewModel

Теперь мы можем получить доступ ко всем свойствам StudentViewModel и унаследованного класса в представлении.

Ответ 8

Много больших примеров, позвольте мне объяснить ясным и хрустящим способом.

ViewModel = Модель, созданная для представления представления.

В представлении ASP.NET MVC не может быть более одной модели, поэтому, если нам нужно отображать свойства из более чем одной модели в представление, это невозможно. ViewModel служит для этой цели.

View Model - это модельный класс, который может содержать только те свойства, которые необходимы для представления. Он также может содержать свойства из нескольких объектов (таблиц) базы данных. Как следует из названия, эта модель создана специально для требований View.

Несколько примеров моделей для просмотра ниже

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

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

Способ создания ViewModel аналогичен созданию модели, способ создания представления для Viewmodel аналогичен созданию представления для модели.

Вот небольшой пример Список данных с помощью ViewModel.

Надеюсь, это будет полезно.

Ответ 9

ViewModel - это обходной путь, исправляющий концептуальную неуклюжесть инфраструктуры MVC. Он представляет 4-й уровень в 3-уровневой архитектуре Model-View-Controller. когда модель (модель предметной области) не подходит, слишком велика (больше, чем 2-3 поля) для представления, мы создаем меньшую модель представления для передачи ее в представление.

Ответ 10

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

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

Ответ 11

  • ViewModel содержит поля, которые представлены в представлении (для помощников LabelFor, EditorFor, DisplayFor)
  • ViewModel может иметь определенные правила проверки с использованием аннотаций данных или IDataErrorInfo.
  • ViewModel может иметь несколько объектов или объектов из разных моделей данных или источника данных.

Проектирование ViewModel

public class UserLoginViewModel 
{ 
[Required(ErrorMessage = "Please enter your username")] 
[Display(Name = "User Name")]
[MaxLength(50)]
public string UserName { get; set; }
 [Required(ErrorMessage = "Please enter your password")]
 [Display(Name = "Password")]
 [MaxLength(50)]
 public string Password { get; set; } 
}

Представление модели представления в представлении

@model MyModels.UserLoginViewModel 
@{
 ViewBag.Title = "User Login";
 Layout = "~/Views/Shared/_Layout.cshtml";
}
@using (Html.BeginForm())
{
<div class="editor-label">
 @Html.LabelFor(m => m.UserName)
</div>
<div class="editor-field">
 @Html.TextBoxFor(m => m.UserName)
 @Html.ValidationMessageFor(m => m.UserName)
</div>
<div class="editor-label">
 @Html.LabelFor(m => m.Password)
</div>
<div class="editor-field">
 @Html.PasswordFor(m => m.Password)
 @Html.ValidationMessageFor(m => m.Password)
</div>
<p>
 <input type="submit" value="Log In" />
</p>
</div>
}

Работа с действием

public ActionResult Login()
{ 
return View();
}
[HttpPost]
public ActionResult Login(UserLoginViewModel user)
{
// To acces data using LINQ
DataClassesDataContext mobjentity = new DataClassesDataContext();
 if (ModelState.IsValid) 
{ 
try
 {
 var q = mobjentity.tblUsers.Where(m => m.UserName == user.UserName && m.Password == user.Password).ToList(); 
 if (q.Count > 0) 
 { 
 return RedirectToAction("MyAccount");
 }
 else
 {
 ModelState.AddModelError("", "The user name or password provided is incorrect.");
 }
 }
 catch (Exception ex)
 {
 } 
 } 
 return View(user);
}
  1. В ViewModel поместите только те поля/данные, которые вы хотите отобразить на представлении/странице.
  2. Так как представление представляет свойства ViewModel, следовательно, оно легко для рендеринга и обслуживания.
  3. Используйте маппер, когда ViewModel становятся более сложными.

Ответ 12

View Model - это класс, который мы можем использовать для визуализации данных в View. Предположим, у вас есть две сущности Place и PlaceCategory, и вы хотите получить доступ к данным обеих сущностей, используя одну модель, тогда мы используем ViewModel.

  public class Place
    {
       public int PlaceId { get; set; }
        public string PlaceName { get; set; }
        public string Latitude { get; set; }
        public string Longitude { get; set; }
        public string BestTime { get; set; }
    }
    public class Category
    {
        public int ID { get; set; }
        public int? PlaceId { get; set; }
        public string PlaceCategoryName { get; set; }
        public string PlaceCategoryType { get; set; }
    }
    public class PlaceCategoryviewModel
    {
        public string PlaceName { get; set; }
        public string BestTime { get; set; }
        public string PlaceCategoryName { get; set; }
        public string PlaceCategoryType { get; set; }
    }

Таким образом, в приведенном выше примере Place и Category являются двумя различными объектами, а ViewCodeory PlaceCategory - это ViewModel, которую мы можем использовать в View.

Ответ 13

Если вы хотите изучить код, как настроить "базовое" веб-приложение с помощью ViewModels, я могу посоветовать загрузить этот код на GitHub: https://github.com/ajsaulsberry/BlipAjax. Я разработал крупные корпоративные приложения. Когда вы делаете это, проблематично настроить хорошую архитектуру, которая обрабатывает все эти функциональные возможности "ViewModel". Я думаю, что с BlipAjax у вас будет очень хороший "базовый уровень" для начала. Это просто простой веб-сайт, но отличный в своей простоте. Мне нравится, как они использовали английский язык, чтобы указать, что действительно нужно в приложении.