Принудить других разработчиков иметь класс проверки - PullRequest
Новая
       22

Принудить других разработчиков иметь класс проверки

0 голосов
/ 08 июля 2019

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

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

 public abstract class CommandHanlder<TCommand> : IRequestHandler<TCommand, ICommandResult> where TCommand : IRequest<ICommandResult>
{
    protected IDbContext DbContext { get; }
    public TCommand Command { get; private set; }

    protected CommandHanlder(IDbContext dbContext)
    {
        DbContext = dbContext;
    }

    public async Task<ICommandResult> Handle(TCommand request, CancellationToken cancellationToken)
    {
        CheckValidation();

        Command = request;

        ICommandResult commandResult;
        commandResult = await Execute();

        return commandResult;
    }

    protected abstract Task<ICommandResult> Execute();

    protected  bool CheckValidation()
    {
        // Need to check whether validation present else should throw a compilation error
        return true;
    }
}

1 Ответ

1 голос
/ 08 июля 2019

Это зависит от того, как вы это настраиваете. Как правило, вы будете довольно ограничены в базовом классе, поскольку он будет иметь видимость только для себя, а не для классов, производных от него. Вы можете добавить абстрактное свойство или метод, но это только гарантирует, что оно «реализовано», а не реализовано правильно. Например, допустим, вы хотите заставить разработчиков реализовать CheckValidation, сделав его абстрактным. Следующее в производном классе будет удовлетворять: 

protected override bool CheckValidation() => true;

Что, очевидно, на самом деле ничего не решает.

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

public abstract class CommandHanlder<TCommand> : IRequestHandler<TCommand, ICommandResult>
    where TCommand : IRequest<ICommandResult>
{
    protected readonly IValidationClass _validationClass;

    protected CommandHandler(IValidationClass validationClass)
    {
        _validationClass = validationClass ?? throw new ArgumentNullException(nameof(validationClass));
    }

    ...
}

Тогда производные классы должны будут предоставить аналогичный конструктор: 

protected MyDerivedCommandHandler(MyValidationClass validationClass)
    : base(validationClass)

Это будет гарантировать, что если не будет передана какая-либо реализация IValidationClass, будет сгенерировано исключение.

Если не считать этого, а может быть, и лучше, это простой обзор кода. Должен быть конвейер сборки и выпуска. Слияние с основной веткой / веткой релиза должно выполняться с помощью запросов извлечения, и для этих запросов извлечения требуется один или несколько проверяющих. Если кто-то добавляет подобный класс без «проверки», вы можете отклонить запросы извлечения, отправив их разработчику для исправления.

...