Проверка на множественные ошибки с одним CustomValidator - PullRequest
Новая
       11

Проверка на множественные ошибки с одним CustomValidator

2 голосов
/ 22 февраля 2010

Я пытаюсь выяснить, как использовать проверку на бизнес-объектах.

До сих пор я видел только примеры на CustomValidator , который проверяет только 1 ошибку. У меня есть два поля с вводом DateTime, которые должны проверять наличие 3 или более ошибок. Я думаю, что обычно я должен проверить на клиенте, а затем на сервере, последний на уровне базы данных.

  • Если я получу ошибку в поле, я не смогу покинуть поле.
  • В проверке клиента это не ошибка, которая должна вызывать исключение, поскольку это только ошибка пользователя. Но если что-то идет не так и пользователь обходит проверку клиента, проверка сервера должна вызвать исключение.
  • И, наконец, если у меня есть другие, например. Пакетное обновление работает, тогда они должны использовать код проверки базы данных. Пожалуйста, поправьте меня, если я пропустил что-то фундаментальное!
  1. `dateFrom` не пусто. (Но `dateTo` может быть пустым)
  2. `dateFrom` раньше, чем` dateTo`
  3. `dateFrom` и` dateTo` находятся в пределах констант `MinDate` и` MaxDate`

Итак, как должна выглядеть моя проверка, клиент, сервер и база данных?

Мысли :

Должна ли логика проверки разделяться на 3 разных места; Пользовательский интерфейс, код и DataObject (база данных)? Когда это точно такой же код? Кажется излишним?

Могу ли я использовать один и тот же метод проверки для всех трех проверок? Или мне нужно реализовать 3 фрагмента кода и 3 метода для каждого, а затем как мне красиво перечислить все в ValidationSummary?

Ответы [ 2 ]

2 голосов
/ 22 февраля 2010

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

Однако, хотя это теоретический идеал, он часто не прагматичен в реальных ситуациях. В среде клиент-сервер, такой как ASP.NET, вы хотите дублировать как можно большую часть проверки на стороне клиента, чтобы уменьшить количество обращений к серверу. Кроме того, если у вас есть другие бизнес-процедуры (например, пакетная загрузка), которые касаются вашей таблицы, не проходя через ваш бизнес-объект, вам потребуется также выполнить проверку в базе данных, чтобы предотвратить создание данных мусора.

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

Для проверки, которую сложно выполнить в JavaScript (т. Е. Требуется бизнес-объект), я не буду беспокоиться о CustomValidator. Вместо этого эти проверки ждут, пока пользователь не нажмет кнопку отправки, после чего я смогу использовать бизнес-объект для проверки себя и возврата любых ошибок.

1 голос
/ 22 февраля 2010

Как правило, проверка на бизнес-уровне - это хорошо; Проверка JS также хороша, потому что она помогает сократить количество поездок в оба конца. Для CustomValidator есть свойство cleintvalidationfunction, которое принимает имя метода для проверки на клиенте, присваивает ему имя метода для проверки (обратитесь к документации MSDN, извините, ссылка не нужна , но у MSDN есть наглядный пример).

Кроме того, для сервера может также возникнуть событие servervalidate для проверки формы из кода, и здесь вы также можете выполнять проверки БД.

Не уверены, какие проверки вы делаете в DataObject (База данных)?

...