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

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

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

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

Эта независимость логики службы от валидации службы очень хороша с практической точки зрения, потому что ее очень легко читать и рассуждать о логике/реализации службы. Тем не менее, я начинаю думать, что правила и наборы правил 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. Спасибо


validation c# fluentvalidation
person Cristóvão    schedule 15.02.2014    source источник

Ответы (1)


arrow_upward
8
arrow_downward

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

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

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

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

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

Подробнее о разнице между проверкой и проверкой можно прочитать здесь.

person Scott    schedule 15.02.2014
comment
Есть ли способ удалить проверку за пределы службы, как это делается с проверкой? - person Cristóvão; 16.02.2014
comment
@Blitzkrieg Вы хотели бы реализовать фильтр запросов, который запускается перед вашей службой. Это отделило бы его по характеру, аналогичному валидации. Важно отметить, что отсутствие записи должно вызывать исключение NotFound, а не исключение проверки. См. здесь фильтры запросов. - person Scott; 16.02.2014
comment
Да, это очевидно... И он выбрасывает 401, 403, 404, 409, 421 и 500 из проверки. Если вы видите в вопросе, я добавил примечание, где я ссылаюсь на это. - person Cristóvão; 16.02.2014
comment
Конечная цель всех, кто публикует/отвечает на SO, состоит в том, чтобы внести свой вклад в процесс создания лучшего программного обеспечения. Я просто указал, что из моего вопроса должно быть очевидно, что я понимаю тот факт, что несуществование должно вызывать исключение NotFound, а не исключение проверки. Только так, не надо расстраиваться по этому поводу. И спасибо за помощь, это не первый раз, когда вы даете мне полезную информацию. - person Cristóvão; 16.02.2014