Проверка ввода данных всегда была для меня довольно внутренней борьбой.
На грани добавления реальной инфраструктуры безопасности и кода в наш проект переписывания старых приложений (который до сих пор в значительной степени сохраняет унаследованный код защиты карты и проверки данных), я снова задаюсь вопросом о том, сколько я должен проверять, где и т. д.
За 5 лет работы в качестве профессионального Java-разработчика я создал и усовершенствовал свои персональные правила для проверки правильности ввода данных и мер безопасности. Поскольку я хотел бы улучшить свои методы, я хотел бы услышать некоторые идеи от вас, ребята. Общие правила и процедуры хороши, а также специфичны для Java.
Подводя итог, это мои рекомендации (представлены в трехуровневом стиле веб-приложения) с краткими пояснениями:
Клиентская часть 1-го уровня (браузер): минимальная проверка, только неизменные правила (обязательное поле электронной почты, необходимо выбрать один элемент и т. П.); реже используется дополнительная проверка, например, «от 6 до 20 символов», так как это увеличивает объем работ по обслуживанию изменений (может быть добавлено после стабилизации бизнес-кода);
Серверная часть 1-го уровня (обработка веб-коммуникации, «контроллеры»): у меня нет правила для этого, но я считаю, что здесь должны обрабатываться только ошибки манипулирования данными и сборки / синтаксического анализа (поле дня рождения недопустимо); добавление дополнительной проверки здесь легко делает этот процесс действительно скучным;
2-й уровень (бизнес-уровень): надежная проверка, не менее; формат входных данных, диапазоны, значения, внутренняя проверка состояния, нельзя ли вызывать метод в любое время, пользовательские роли / разрешения и т. д .; используйте как можно меньше пользовательских вводимых данных, при необходимости извлеките их снова из базы данных; если мы также рассматриваем полученные данные базы данных как входные данные, я проверю их только в том случае, если известно, что некоторые конкретные данные ненадежны или достаточно повреждены в БД - строгая типизация выполняет большую часть работы здесь, IMHO;
3-й уровень (уровень данных / DAL / DAO): никогда не считалось, что здесь требуется много проверки, так как только бизнес-уровень должен получить доступ к данным (возможно, в некоторых случаях может быть проверка, например, «param2 не должен быть нулевым, если param1 истинно»); заметьте, однако, что когда я имею в виду «здесь», я имею в виду «код, который обращается к базе данных» или «методы выполнения SQL», сама база данных полностью противоположна;
база данных (модель данных): должна быть продуманной, сильной и самодостаточной, чтобы максимально избежать некорректных и поврежденных данных в БД, с хорошими первичными ключами, внешними ключами, ограничениями, типом данных / длиной / размером / точность и т. д. - я оставляю триггеры из-за этого, так как у них есть свое личное обсуждение.
Я знаю, что ранняя проверка данных хороша и влияет на производительность, но повторная проверка данных - это скучный процесс, и я признаю, что сама проверка данных довольно раздражает. Вот почему так много кодеров пропускают это или делают это наполовину. Кроме того, каждая дублированная проверка является возможной ошибкой, если они не синхронизируются все время. Это основные причины, по которым я в настоящее время предпочитаю, чтобы большинство проверок доходило до бизнес-уровня за счет времени, пропускной способности и ЦП, а исключения обрабатывались в каждом конкретном случае.
так что ты думаешь об этом? Противоположные мнения? У вас есть другие процедуры? Ссылка на такую тему? Любой вклад действителен.
Примечание: если вы думаете о способе работы Java, наше приложение основано на Spring с Spring MVC и MyBatis (производительность и плохая модель базы данных исключают решения ORM); Я планирую добавить Spring Security в качестве нашего поставщика безопасности плюс JSR 303 (Hibernate Validator?)
Благодарность!
Изменить: некоторые дополнительные разъяснения на 3-м слое.