Архитектура ASP.NET в MVC: модель представления по составу, наследования или дублирования?

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

public class EditUserModel {    
  public string Name { get; set; }    
  public string Email { get; set; }    
  public string Password { get; set; }        
  public string ConfirmPassword { get; set; }        
}

если идентификатор хранится в url. Если вы хотите избежать копирования вручную между экземплярами User и EditorUserModel,AutoMapper могу помочь вам. Таким образом, вы можете легко отделить строку пароля в модели представления от хэша пароля в модели домена.

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

У вас есть модель пользователя со всеми проверки:

public class UserModel
{
    [Required]
    public int Id { get; set; }
    [Required]
    public string Name { get; set; }
    public string Email { get; set; }
    public string Password { get; set; }        
}

вы составляете предыдущую модель с новой моделью

public class EditUserModel
{
    public UserModel User { get; set; }

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

трюк в действии, вы можете получить более одной модели:

[HtttPost]
public ActionResult UpdateInformation(UserModel user, EditUserModel editUserModel) {
    if (ModelState.IsValid) {
         // copy the inner model to the outer model, workaround here:
         editUserModel.User = user
         // do whatever you want with editUserModel, it has all the needed information
    }
}

таким образом, проверка работает ожидаемый.

надеюсь, что это помогает.

Я не использую модели сущностей слишком много, я предпочитаю модели LINQ-SQL, поэтому это может быть неверно:

почему бы не использовать класс метаданных, который применяется к сущности? С LINQ-SQL назначенные метаданные учитываются как на стороне клиента, так и на стороне сервера.

из того, что я понимаю, применение атрибута [MetaDataType] похоже на наследование, только оно работает без реализации нового класса (модели) для изменений в базовом сущность.

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

поэтому я бы определил сущность следующим образом:

public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public string Password { get; set; }     

    [DoNotPersist]   
    public string ConfirmPassword {get; set;}

}

кроме того, я не знаю, что вы делаете для хранения данных, но я подключил переопределение в функции OnInserting, OnEditing, OnDeleting для моего DataContext, которые в основном удаляли любые члены, имеющие мой настраиваемый атрибут.

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

надеюсь, что это поможет!

PS: - композиция vs наследование-это действительно зависит от целевого пользователя приложения. Если это для приложения интрасети, где безопасность меньше проблем, а среда пользователя / браузера контролируется, то просто используйте проверку на стороне клиента, т. е.: состав.

Я бы предпочел композицию наследованию.

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

вы должны хранить только соленый хэш, и ваш EditUserModel должны иметь два свойства строки для пароля и подтверждения пароля, которые не являются полями в таблице.