Я работаю над проектом ASP.NET MVC 2 с некоторыми бизнес-объектами, к которым применены атрибуты аннотаций метаданных (атрибуты проверки, атрибуты отображения и т. Д.).
Что-то вроде:
//User entity
public class User
{
[DisplayName("Vorname")]
[Required(ErrorMessage = "Vorname fehlt")]
[StringLength(MaxNameLength, ErrorMessage = "Vorname ist zu lang")]
public string FirstName { get; set; }
[DisplayName("Nachname")]
[Required(ErrorMessage = "Nachnamefehlt")]
[StringLength(MaxNameLength, ErrorMessage = "Nachname ist zu lang")]
public string LastName { get; set; }
[Required]
public string Password{ get; set; }
}
Использование метаданных из разных представлений не представляет проблем, если я использую свои бизнес-объекты в качестве моделей представления или как часть модели представления, подобной этой:
//custom viewmodel with a user entity
public class CustomViewModel
{
public User{get;set;}
//some more properties...
}
Однако иногда мне нужно кодировать представление для редактирования некоторых, но не всех полей сущности. Для этих полей я хочу повторно использовать метаданные, уже указанные в моем пользовательском объекте. Остальные поля следует игнорировать. Я говорю о пользовательских моделях вида как это:
[MetadataType(typeof(User))]
public class UserNameViewModel
{
public string FirstName { get; set; }
public string LastName { get; set; }
//no password on purpose, the user should only
//edit his first and last name in this view
}
Вот где я сталкиваюсь с проблемами. Приведенная выше модель пользовательского представления приводит к исключению при создании представления, поскольку оно не имеет свойства пароля.
Связанный тип метаданных для типа
'Zeiterfassung.Models.ViewModels.Users.UserNameViewModel + UserModel'
содержит следующее неизвестное
свойства или поля: пароль. Пожалуйста, убедитесь, что
что имена этих членов совпадают
названия свойств на
основной тип.
Кроме того, даже если это исключение не произошло, я ожидаю еще больше проблем с проверкой модели при отправке формы, поскольку пароль помечен как обязательный для моей бизнес-сущности.
Я могу придумать несколько обходных путей, но ни один из них не кажется действительно идеальным. В любом случае я не могу изменить структуру базы данных так, чтобы поле пароля было в отдельной сущности в моем примере выше.
Как бы вы справились с этим сценарием?