Где вы регистрируете правила проверки данных формы в веб-приложении?

Ответ 1

все вышесказанное:

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

EDIT: я вижу, что вы отредактировали вопрос, чтобы задать единую точку спецификации для правил проверки. Это называется "Словарем данных" (DD), и это хорошая вещь, которая должна иметь и использовать для генерации правил проверки в разных слоях. Тем не менее, большинство систем не так плохо, если вы никогда не обойдетесь в строительство такой вещи; -)

Один возможный/простой дизайн для DD для современной трехуровневой системы может включать в себя - наряду с обычной информацией о максимальном размере/мини-размер/тип данных - поле выражения/функции Javascript, сборку/класс/метод С# поле и поле выражения sql. Javascript может быть вставлен на проверку на стороне клиента, информация С# может использоваться для загрузки/вызова отражения для проверки на стороне сервера, а выражение sql может использоваться для проверки базы данных.

Но в то время как все это хорошо в теории, я не знаю никаких реальных систем, которые на самом деле делают это на практике [хотя это "звучит" как хорошая идея].

Если да, сообщите нам, как это происходит!

Ответ 2

Чтобы ответить на реальный вопрос:

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

Но опять же, вы хотите, чтобы ограничения базы данных отражались в вашей дате. Таким образом, первое приближение, вероятно, должно было бы определить какой-то небольшой набор пердикатов, который является mappeble для проверки ограничений, системного языка и javascript.

Либо это, либо просто позаботьтесь о трех представлениях в одном месте, чтобы вы не заставляли их синхронизировать при изменении чего-либо.

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

Возможно, путь - это определить небольшой управляемый DSL для perdicates, описывающий ограничение. Затем вы создаете "компиляторы", которые анализируют этот DSL и предоставляют необходимое вам представление.

"DSL" не обязательно должна быть такой фантастической, простой строкой и проверкой int не такая уж большая проблема. Проверка RegEx может быть проблемой, если ваша база данных ее не поддерживает. Возможно, вы можете создать этот DSL как просто набор классов или то, что предоставляет ваш системный язык, которые можно объединить в выражения с простой булевой алгеброй.

Ответ 3

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

{ "fieldName1" : "error description", 
"fieldName2" : "another error description" };

Форма отправляется, если сервер возвращает пустой объект, иначе я могу использовать информацию с сервера для отображения ошибок. Он работает так же, как эти формы регистрации, которые проверяют, был ли ваш логин принят до того, как вы отправите форму, с двумя ключевыми отличиями: запрос отправляется onsubmit и отправляет все значения полей (кроме input type="file").

Если по какой-либо причине проверка JavaScript не работала, выполняется обычный сценарий проверки на стороне сервера (перезагрузка страницы с информацией об ошибках) с использованием той же серверной стороны script.

Это решение не так отзывчиво, как чистая проверка на стороне клиента (требуется время для отправки/получения данных между клиентом и сервером), но это довольно просто, и вам не нужно "переводить" правила проверки на JavaScript.

Ответ 4

Всегда проверяйте каждую входную серверную сторону. Вы не знаете, что их клиент поддерживает javascript "правильно", или что они не подделывают свои HTTP-запросы и полностью обходят ваш javascript.

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

Ответ 5

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

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

Таким образом, если вам когда-либо понадобится изменить правило, у вас будет одно место.

Ответ 6

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

Один подход, используемый несколькими структурами веб-разработки (включая CakePHP) Является ли организация вашего кода в объекты Model, View, Controller.

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

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

Наконец, используйте это регулярное выражение для проверки в javascript (view) и в коде обработки формы сервера (Controller).

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

Я поставлю вилку для начала с хорошей структурой, поэтому вам не придется все это прокладывать самостоятельно.

Ответ 7

Хорошее решение для проверки данных может использовать XML Schema определение типов данных, тогда как клиент, так и сервер будут повторно использовать типы, поскольку они будут оба должны выполнить его. Следует отметить, что Backbase Ajax Framework реализует проверку входных данных на стороне клиента на основе типов данных XML Schema (встроенных и определяемых пользователем)

Ответ 8

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

Ответ 9

Мы стараемся, чтобы наша проверка была сделана до того, как она когда-либо попадет на сервер базы данных, особенно для наших приложений, которые стоят перед общедоступным Интернетом. Если вы не выполните проверку до того, как данные попадут в базу данных, вы подвергли свою базу данных риску атаки SQL-инъекций. Мы проверяем с помощью javascript и кода.

Ответ 10

В прошлом я использовал XSLT для проверки. Мы создадим XML-документ значений и запускаем его против XSLT. XSLT был построен из правил XPath. В результате XML-документ был составлен из списка нарушенных правил и полей, которые их нарушили.

Мы смогли:

• сохранить правила в реляционной БД
• генерирует XSLT из базы данных
• используйте XSLT на клиенте
• используйте XSLT на сервере
• используйте исходные правила в DB