Согласованные правила проверки как для модели Dto, так и для модели домена

Я хочу проверить как свои модели Dto, так и модели домена с помощью FluentValidation. Я уже определил класс Validator для проверки моего Dto, как показано ниже.

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

Есть ли способ потенциально унаследовать правила от модели предметной области или чего-то подобного, чтобы достичь согласованных правил в моделях Dto и Domain?

Dto:

public class NewUserDto
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Username { get; set; }
    public string Email { get; set; }
    public string Password { get; set; }
}

public class NewUserDtoValidator : AbstractValidator<NewUserDto>
{
    public NewUserDtoValidator()
    {
        RuleFor(x => x.FirstName).Length(2, 50);
        RuleFor(x => x.LastName).Length(2, 50);
        RuleFor(x => x.Email).EmailAddress();
        RuleFor(x => x.Username).Length(4, 25);
        RuleFor(x => x.Password).MinimumLength(6);
    }
}

Модель домена:

public class User
{
    public uint Id { get; private set; }

    public string Username { get; private set; }
    public string FirstName { get; private set; }
    public string LastName { get; private set; }
    public string Email { get; private set; }
    public DateTime RegistrationDate { get; private set; }
    public string Hash { get; private set; }
    public string Salt { get; private set; }
}

person bbartels    schedule 03.02.2018    source источник
comment
Если бы вам пришлось выбирать, проверка моделей предметной области наиболее важна, потому что именно там и находится настоящая логика. Если вы всегда работаете с допустимыми моделями домена, то DTO, возвращенные из домена, будут действительными, а недопустимые DTO, поступающие в домен, будут отклонены, если их нельзя использовать для формирования действительных моделей домена.   -  person Scott Hannen    schedule 03.02.2018
comment
@ScottHannen Но я хотел бы объяснить, почему DTO, отправленный клиентом, недействителен, и я действительно не хочу возвращать клиенту сообщения об ошибках бизнес-уровня. Я чувствую, что эта проблема должна встречаться чаще. Не совсем уверен, почему нет простого способа сделать это.   -  person bbartels    schedule 04.02.2018
comment
Я не говорю, что не проверяйте dto. Но это звучало так, как будто вы проверяли dto вместо модели предметной области или сомневались в том, где проверить.   -  person Scott Hannen    schedule 04.02.2018
comment
@ScottHannen Я хочу проверить и то, и другое. Я искал способ разделить логику между проверкой Dto и моделью домена. Поэтому мне, когда в правилах происходят изменения, мне не нужно обновлять каждое Dto, относящееся к этой модели предметной области.   -  person bbartels    schedule 04.02.2018
comment
Если это не противоречит вашему дизайну, вы можете создать интерфейс для общих полей и базовый валидатор: class BaseUserValidator: AbstractValidator<IUser> {}   -  person Roman Koliada    schedule 06.02.2018
comment
@bbartels Вот такие проблемы не дают мне уснуть в 2 часа ночи. Какой подход вы выбрали для этого? В настоящее время проект, с которым я работаю, достаточно прост, чтобы я не беспокоился о DTO - я десериализуюсь прямо в сущности домена и применяю для них правила проверки через FluentValidation. Однако, возможно, мне пора создать DTO, но с этим возникает беспокойство по поводу дублирования не только данных, но и логики проверки.   -  person Tagc    schedule 29.06.2020


Ответы (1)


Для совместного использования одних и тех же правил проверки между объектами вы можете использовать настраиваемые валидаторы: https://github.com/JeremySkinner/FluentValidation/wiki/e.-Custom-Validators

person Vladislav Rastrusny    schedule 04.02.2018