Лучшая практика для проверки входных данных для многоуровневого приложения [закрыто

Question

В нашем приложении у нас есть различные слои. Служба, слой DAO и действия (приложения на расстояниях).

Данные передаются из одного слоя в другой слой.

Где мы должны в идеале поставить проверку ввода?

Скажем, пользовательский, номер телефона поступает из пользовательского интерфейса, они обязательны. Таким образом, мы уже выполняем проверку на стороне клиента.

Теперь, по моему мнению, все, что вам нужно. Нет, где еще это должно быть подтверждено.

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

Теперь, в DAO, тот же метод используется в каком -то другом действии, и это не имеет проверки,

Или, скажем, уровень обслуживания, он может быть выявлен как, скажем, как веб -сервис, так что там также есть проверка.

По сути, он предлагает ... у нас есть подтверждения повсюду. Что не имеет смысла для меня. Его дублирование по слону.

Какой идеальный подход для этого? Скажем, валидация может быть простой проверкой или какой -то сложной проверкой.

Answer 1

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

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

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

На уровне сервера вы хотите предположить, что все входы потенциально опасны и неверны (и они часто будут). Я на самом деле думаю, что лучше быть более полным и агрессивным в проверке входных данных на уровне обслуживания, так как это ваша последняя линия защиты. Если вы оставите проверку или два на стороне клиента, вам просто нужен хороший механизм обработки разломов, чтобы пользователи знали, что не так. Если вы пропустите что -то на стороне обслуживания и стихийных ударах, это может означать часы или дни отладки и попытки восстановить резервные копии базы данных.

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

Answer 2

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

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

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

Answer 3

Единственная часть мудрости, которую я могу добавить в разговор, никогда не доверяйте клиенту. Будет ли ваш клиент в HTML, Flash/Flex или что -то еще, есть вероятность того, что кто -то собирается взломать его и попытаться сделать то, что вы не хотите, чтобы он делал. Последующее наблюдение состоит в том, что если есть вероятность того, что кто -то собирается взломать его, мы, как разработчики программного обеспечения Вы должны проверить все свои входы на заднем плане, даже если это приводит к дублирующим проверкам.