MVC и NOSQL: Сохранение моделей представления непосредственно в MongoDB?

Я понимаю, что «правильная» структура для разделения задач в MVC - иметь модели представлений для структурирования ваших представлений и отдельные модели данных для сохранения в выбранном вами репозитории. Я начал экспериментировать с MongoDB и начинаю думать, что это может не применяться при использовании базы данных без схемы в стиле NO-SQL. Я хотел представить этот сценарий сообществу stackoverflow и узнать, что все думают. Я новичок в MVC, поэтому для меня это имело смысл, но, возможно, я что-то упускаю ...

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

public class UserEditModel
{
    public string Username
    {
        get { return Info.Username; }
        set { Info.Username = value; }
    }

    [Required]
    [MembershipPassword]
    [DataType(DataType.Password)]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [DisplayName("Confirm Password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }

    [Required]
    [Email]
    public string Email { get; set; }

    public UserInfo Info { get; set; }
    public Dictionary<string, bool> Roles { get; set; }
}

public class UserInfo : IRepoData
{
    [ScaffoldColumn(false)]
    public Guid _id { get; set; }

    [ScaffoldColumn(false)]
    public DateTime Timestamp { get; set; }

    [Required]
    [DisplayName("Username")]
    [ScaffoldColumn(false)]
    public string Username { get; set; }

    [Required]
    [DisplayName("First Name")]
    public string FirstName { get; set; }

    [Required]
    [DisplayName("Last Name")]
    public string LastName { get; set; }

    [ScaffoldColumn(false)]
    public string Theme { get; set; }

    [ScaffoldColumn(false)]
    public bool IsADUser { get; set; }
}

Обратите внимание, что класс UserEditModel содержит экземпляр UserInfo, который наследуется от IRepoData? UserInfo - это то, что сохраняется в базе данных. У меня есть общий класс репозитория, который принимает любой объект, наследующий форму IRepoData, и сохраняет его; поэтому я просто вызываю Repository.Save (myUserInfo) и готово. IRepoData определяет _id (соглашение об именах MongoDB) и метку времени, поэтому репозиторий может выполнять обновление на основе _id и проверять наличие конфликтов на основе метки времени и любых других свойств, которые объект только что был сохранен в MongoDB. Представление, по большей части, просто нужно использовать (скрыть), и мы в порядке! По сути, все, что требуется только представлению, входит в базовую модель, все, что требуется только репозиторию, просто получает аннотацию [ScaffoldColumn (false)] , а все остальное является общим между ними. (Кстати - имя пользователя, пароль, роли и адрес электронной почты сохраняются для поставщиков .NET, поэтому они не входят в объект UserInfo.)

Большие преимущества этого сценария двоякие ...

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

2. Я могу повторно фактор в секундах ... Если мне нужно добавить второй адрес электронной почты, я просто добавляю его к объекту UserInfo - он добавляется в представление и сохраняется в репозиторий, просто добавляя одно свойство к объекту. Поскольку я использую MongoDB, мне не нужно изменять схему моей базы данных или связываться с любыми существующими данными.

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

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