ServiceStack - проверка и доступ к базе данных

Question

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

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

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

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

Вопросы:

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

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

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

остальное я делать вручную. Любой, у кого есть решение этой проблемы?

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

Answer 1

Да, неверно выполнять проверку наличия записи базы данных в логике проверки, поскольку это не проверка проверки. Вот почему это не делается в примерах таким образом.

Проверка наличия записи проверка проверка. В качестве примера, чтобы проиллюстрировать это:

Если вы берете номер кредитной карты, вы можете использовать Luhn Algorithm, чтобы подтвердить, что номер кредитной карты действителен. Это будет сделано в валидаторе, потому что это проверка.

Но только потому, что у вас есть действительный номер, это не значит, что он существует, у вас может быть действительный номер для еще не выпущенной карты. Было бы неверно использовать валидатор для проверки того, что он существует, поскольку это процесс проверки и должен выполняться в бизнес-логике.

Когда вы начинаете использовать базу данных для проверки наличия вещей, которые вы выходите из области проверки, потому что вы должны только когда-либо передавать проверенные данные в базу данных.

Вы можете узнать больше о difference between validation and verification here.