MVC с использованием моделей доменов в моделях просмотра

Выполняется ли следующее ОК? Я знаю, что модели домена никогда не должны использоваться в представлениях, но нормально ли использовать модели домена в моделях просмотра? Для некоторых очень маленьких моделей, похоже, не стоит создавать и управлять моделью просмотра для них.

Пример

public class LoginDomainModel
{
    public string Email { get; set; }
    public string Password { get; set; }
    public string DisplayName { get; set; }
    public long UserTypeID { get; set; }      
    public virtual UserType UserType { get; set; } 
}
public class UserTypeDomainModel
{
    public UserType()
    {
        this.Logins = new List<Login>();
    }
    public long UserTypeID { get; set; }
    public string UserType { get; set; }
    public string Description { get; set; }
    public virtual ICollection<Login> Logins { get; set; }
}

public class LoginViewModel
{
    public string Email { get; set; }
    public long UserTypeID {get; set;}

    //Right here
    public List<UserTypeDomainModel> UserTypesSelectList {get; set;}
}

Ответ 1

Лично я использую модели домена в представлении, если они, естественно, будут точными. Вероятно, это произойдет только в отношении тривиальных проектов, которые являются CRUD в природе (прямое редактирование объектов домена). Я считаю, что это пустая трата времени, чтобы создать точную копию доменного объекта ради чистоты.

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

Ответ 2

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

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

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

Я не вижу абсолютной необходимости создавать отдельную модель представления для readonly, несвязанных значений (возможно, список типов пользователей в вашем случае, хотя public virtual ICollection<Login> Logins может отрицать это).

В качестве альтернативы вы можете спроецировать модель домена на абстракцию, ориентированную на UI (например, IEnumerable<SelectListItem>). Вы можете использовать SelectListItems для различных механизмов ввода, поэтому вы не привязываетесь к определенному поведению пользовательского интерфейса.

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

TL;DR: абстрактные модели домена, насколько это практически возможно, найти соответствующие абстракции (новая модель представления не всегда является правильным ответом) и быть (слегка параноидально) относительно проверки ввода. p >

Ответ 3

Это зависит от того, что вы подразумеваете под "моделью домена". Вы имеете в виду объекты EF? Или вы имеете в виду объекты бизнес-уровня?

Никогда не рекомендуется передавать объекты EF в представление, особенно если вы используете привязку модели по умолчанию. Это может привести к проблемам безопасности, если вы не будете осторожны. Хотя те же проблемы могут возникнуть, если вы не будете осторожны с бизнес-объектами, переданными в представление.

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

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