Я реализую API с ServiceStack. Одним из ключевых аспектов моего решения является агрессивная стратегия проверки.

Я использую ServiceStack's ValidationFeature, что означает, что если в контейнере приложения зарегистрирован IValidator <ReqDto> (или его потомок: AbstractValidator <ReqDto>), проверка будет выполняться автоматически перед обслуживанием.

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

Эта независимость Service Logic от Service Validation является чем-то действительно хорошим с практической точки зрения, потому что она очень легко читается и рассуждает о логике / реализации Service. Однако я начинаю думать, что правила и наборы правил FluentValidation лучше подходят для простых проверок формата, а не для прямого доступа к базе данных, как я (в основном, для проверки на 404 ошибки, возникшие из идентификаторов, извлеченных из запроса).

Вопросы:

1: неверно ли концептуально для логики валидации доступ к базе данных?

2: Из того, что я видел до сих пор, включая источник SS, я не нашел форму для определения правила FluentValidation для таких случаев, как: извлечение идентификатора из запроса, доступ к базе данных, получение объекта и выдача 404, если запись не была найдена. Я использую правила FV только для определения основных проверок формата, таких как:

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

Остальное я делаю вручную. Кто-нибудь с решением этой проблемы?

ПРИМЕЧАНИЕ. Это не вопрос о том, как преобразовать ValidationResult / ValidationError в HttpResult / HttpError. Я рассмотрел это с помощью ErrorResponseFilter ValidationFeature, который был представлен в SS 3.9.44. Спасибо