Estou implementando uma API com ServiceStack. Um dos aspectos principais da minha solução é uma estratégia agressiva de validação.

Uso ValidationFeature do ServiceStack, o que significa que, se houver um IValidator <ReqDto> (ou seu descendente: AbstractValidator <ReqDto>) registrado no contêiner do aplicativo, a validação será executada automaticamente antes do serviço.

Por validação agressiva, o que quero dizer é que verifico todos os cenários de erro possíveis e validações lógicas no nível do validador. Como resultado, minha lógica de serviço é extremamente limpa e curta.

Essa independência da Lógica de Serviço e da Validação de Serviço é algo realmente agradável do ponto de vista prático, porque fornece uma leitura e uma razão muito fáceis sobre a lógica / implementação do Serviço. No entanto, estou começando a pensar que as Regras e o RuleSets do FluentValidation são mais adequados para validações de formato simples, e não diretamente nos acessos ao banco de dados como estou fazendo (principalmente para testar erros 404 originados de IDs retirados da solicitação).

Questões:

1: É incorreto conceitualmente que a lógica de validação acesse o banco de dados?

2: Pelo que vi até agora, incluindo a fonte SS, não encontrei um formulário para definir uma regra FluentValidation para casos como: extrair um ID da solicitação, acessar o banco de dados, recuperar uma entidade e lançar um 404 se um entrada não foi encontrada. Eu só uso as regras da FV para definir validações básicas de formato, como:

RuleFor(x => x.UserName).NotEmpty();
RuleFor(x => x.Password).NotEmpty();

O resto eu faço manualmente. Alguém com uma solução para esse problema?

NOTA: Esta não é uma pergunta sobre como transformar um ValidationResult / ValidationError em um HttpResult / HttpError. Eu que cobri, usando o ErrorResponseFilter da ValidationFeature que foi introduzido na SS 3.9.44. obrigado