Каковы лучшие практики для проверки пользовательских элементов управления ASP.Net? - PullRequest
0 голосов
/ 27 марта 2009

Мне интересно, существуют ли какие-либо передовые практики для руководства относительно того, что должно и не должно входить в контроль валидатора. Моя мысль и практика заключались в том, что это должна быть базовая проверка работоспособности (т. Е. Ввел ли пользователь все необходимые данные? Есть ли в номере 10 цифр, адрес электронной почты в действительной форме? И т. Д.), Но я недавно наткнулся на довольно много кода asp.net, который использует валидаторы для более сложной проверки (т. е. вызовы веб-службы для проверки адресов или совпадения идентификатора и имени пользователя).

Существуют ли какие-либо школы мысли о том, как эти более сложные задачи должны быть заключены в капсулу? Мой первоначальный инстинкт был в том, что валидаторы - не тот инструмент для работы, но мне бы очень хотелось узнать, что другие люди думают или пишут об этом. Спасибо!

Ответы [ 2 ]

0 голосов
/ 26 февраля 2010

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

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

0 голосов
/ 27 марта 2009

Ты прав. У команды p & p есть замечательный блок в Enterprise Library, названный Блок приложения проверки (VAB).

Проверка в пользовательском интерфейсе хороша, если вы собираете значения непосредственно от пользователей, но вам может потребоваться сделать больше. Например, вам может потребоваться проверить экземпляры объектов, которые вы:

  • Генерация в отдельных уровнях или компонентах вашего приложения
  • Извлечение из кэша, хранилища или стороннего уровня доступа к данным
  • Получение от веб-службы в виде экземпляра объекта или набора значений свойств
  • Реконструкция из существующих значений, возможно заполнение их путем копирования свойств из аналогичного объекта или использования значений, извлеченных из базы данных

Я большой поклонник Enterprise Library и имею хороший опыт работы с VAB. Если вы не знакомы с EntLib, это может быть трудно в первый раз, но после этого он будет крут!

VAB дает вам возможность создавать, запускать и размещать ваши правила в одном месте, но звонить туда, где вам это нужно.

15 секунд с ASP.NET и VAB:

http://www.15seconds.com/Issue/070607.htm

Блог Тома Холландера о VAB

http://blogs.msdn.com/tomholl/archive/2006/11/27/validation-application-block-revealed.aspx

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...