В какой степени проверка уровня должна выполняться в реальном приложении на базе Java?

Question

Я работал разработчиком в нескольких корпоративных приложениях, в основном основанных на Spring Framework и Java EE (главным образом EJB); но не на всех слоях (уровень обзора является наименее обработанным)

Рассмотрение многоуровневого приложения (уровень клиента, бизнес-уровень, уровень данных и т. д.) На каком уровне должна выполняться проверка данных?

Я слышал Bean проверки API а именно: JSR 303; но проверки выполняются в Beans, то есть на стороне сервера (если я правильно понял).

Итак, в реальных приложениях, где должна проводиться проверка? Если какая-либо проверка выполняется на самом клиентском уровне (например, если используемая технология просмотра - JSP, должна ли проверка выполняться в JSP)? Если да, то в чем преимущество JSR 303.

Также не имеет смысла, чтобы данные, передаваемые от клиента на сервер, были отклонены из-за валидаций, я не совсем понимаю, каков правильный подход к проверке.

Любое объяснение в понимании этого хорошо оценено.

Answer 1

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

Но иногда вы просто не можете этого сделать, поэтому вам нужна проверка на стороне сервера. Например, как вы можете проверить, что логин уже сделан на странице регистрации?

Иногда проверка даже идет глубже в слой данных. Ограничения целостности данных, например, являются проверкой уровня данных (ссылочная целостность, обнуление, ...).

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

Answer 2

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

1. Преимущество проверки на стороне клиента заключается в том, что у вас есть контроль, чтобы предупреждать пользователя, когда он когда-либо был, и немедленно показывать связанные сообщения. Но не забывайте избегать сложных логик, таких как сопоставление дат, как проверки, потому что на бэкэнд у вас будет достаточно свободы для проверки на различные ограничения.
2. Его всегда лучше выполнять проверку подлинности на уровне бизнеса, который может стать самой сильной частью вашего приложения. Это обеспечивает безупречные выходные данные, не забывайте бросать пользовательские исключения, что делает приложение более удобным и использует существующие методы для валидации {напр. isDigit(), isEmpty() и т. д.}.
3. На уровне уровня данных старайтесь минимизировать валидации, но иногда мы должны включать их, если есть зависимость от других служб и т. Д.

Что касается JSR 303, проверка боб, это помогает как растяжение руки, чтобы упростить проверку полей ввода пользователя, которые сопоставляются с фасолью {обычно весной приложения на основе с REST}

А относительно вашего сомнения «Также не имеет смысла переводить данные с клиента на сервер из-за валидации« .. это может выглядеть так, но его действительно важно иметь поток таким образом, чтобы обрабатывать проверки с использованием сложных логик и к исключениям лучше.

Answer 3

Обычно в приложении имеется 3 слоя. Слой модели, слой управления и слой «Вид». Каждый уровень имеет свою логику проверки.

Просмотреть уровень проверки проверки входных данных пользователя. Эта проверка полезна для удобства пользователей и производительности сервера, поскольку она может указывать на недопустимый вход пользователя раньше и избегать недействительного вызова интерфейса сервера. Уровень проверки в представлении должен в основном касаться проверки входа пользователя (например: проверка формата электронной почты, проверка формата пароля и т. Д.).

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

Проверка уровня модели в основном связана с проверкой данных. Просмотрите адрес электронной почты для выбранного слоя, а уровень модели проверяет, зарегистрировано ли электронное письмо в приложении (возможно, данные пользователя хранятся в db или кеше).

Одним словом, каждый слой несет свою ответственность, и он должен выполнять соответствующую проверку данных.

Answer 4

Я думаю, что говорить о валидации - это говорить о подходе не к решению.

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

JSR303 - это тип проверки: проверка валиков.

Другой валидация может быть:

• проверка против любого вида инъекций
• проверки для аутентификации/авторизации

О повторном использовании: если вы звоните бизнес-слой, который полагается на проверки на стороне клиента то вызов B2B не может использовать проверку.

Помимо этих соображений, есть хорошие советы. Например, don't trust client side validation.

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