Как избежать дублирования проверки на веб-уровне и уровне обслуживания?

Question

Если у меня есть веб-приложение, скажем, я использую Spring MVC, и я добавляю проверку в мои формы и контроллеры. У меня также может быть проверка на уровне службы, если клиенты получают доступ к моему приложению другим способом (через службу REST и т. Д.). В этом случае у меня может быть логика / код проверки в нескольких местах.

Существует ли предлагаемый подход для сохранения части проверки СУХОЙ?

Answer 1

Многие люди скажут вам, как это сделать. Я собираюсь ответить, почему вы можете этого не хотеть.

В N-уровневой системе все уровни работают полуавтономно. Но это не значит, что они могут - или должны - полагаться на другой уровень, чтобы гарантировать согласованность и достоверность данных.

Есть две основные причины. Во-первых, N-уровневая система расширяема. Например, в веб-системе новый интерфейс может использовать преимущества существующего веб-уровня, чтобы сделать что-то, о чем никогда не думали в оригинальном дизайне. Таким образом, вы разрабатываете систему для проверки своей системы, позволяя чему-то новому появиться в некоторой средней точке уровней.

Во-вторых, валидация часто наиболее эффективна, чем ближе к пользователю. Если я использую решение на основе браузера и ввожу неверный пароль в поле проверки с двойным вводом, я бы хотел, чтобы браузер немедленно указал на это. Ожидание поездки туда и обратно требует времени и разочаровывает пользователя.

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

Это просто философия, но она хорошо работала для меня в прошлом.

Answer 2

Я хотел бы предложить, чтобы это были разные виды проверки.

Проверки проверки клиента / контроллера для проверки наличия требуемых значений, соблюдения форматов и т. Д.в объекты, которые должны быть переданы на уровень обслуживания, является исключительной ответственностью контроллера.

Уровень обслуживания будет выполнять те же проверки, что и на стороне клиента, но также добавит «проверки бизнеса», которые относятся к сценарию использования,Контроллер не может их знать.

Один из способов избежать дублирования - выполнять одинаковые функции JavaScript на стороне клиента и сервера.На стороне сервера используется механизм JavaScript для выполнения проверок клиента, а также дополнительные проверки, относящиеся к проверке бизнеса.

Answer 3

Вероятно, стоило бы взглянуть на проверку bean-компонента JSR-303. Если вы используете одни и те же JavaBean-компоненты для разных интерфейсов, вы можете избежать дублирования логики проверки.

Реализация Hibernate предоставляет лучшую справочную документацию:

http://hibernate.org/subprojects/validator

И справочные документы Spring расскажут вам, как его интегрировать.

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/validation.html#validation-beanvalidation-overview

Answer 4

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

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

Answer 5

Spring использует интерфейс validator . Это один из способов.Я не знаю причину, почему вы не можете использовать это на уровне обслуживания.В качестве альтернативы, вы можете использовать AOP и определять pointcuts по мере необходимости на любом уровне.