Каков хороший подход к работе с повторяющимися и длинными кодами проверки? - PullRequest
0 голосов
/ 14 сентября 2009

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

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

Или есть ли лучшие и более эффективные способы?

Ответы [ 3 ]

2 голосов
/ 14 сентября 2009

Я использую Zend_Validate с Zend_Forms для проверки, в которой код проверки находится в методе init форм. Все, что мне нужно сделать, это передать массив валидаторов для каждого элемента и затем запустить ..

$form->isValid($data);

... вне формы для проверки данных.

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

И действительно легко определить новые валидаторы в Zend.

edit: я обнаружил платформу, расширяющую Zend Framework, которая позволяет объектам домена содержать свою собственную проверку. Он называется Xyster Framework, но я не смог заставить его работать с первой попытки, поэтому я не пробовал после этого.

2 голосов
/ 16 сентября 2009

Я бы настоятельно рекомендовал поработать над включением проверки в модель. Как только вы сможете сделать одно, любые другие, которые вы создадите, будут намного легче. Кроме того, если у вас есть несколько контроллеров, пытающихся сохранить эти данные, вам не нужно перекодировать валидацию. Документы Kohana содержат несколько примеров для интеграции библиотеки валидации и ORM, с чего вам следует начать.

0 голосов
/ 14 сентября 2009

Вот моя стратегия работы с кодом проверки. Я предполагаю, что под «библиотекой проверки» вы подразумеваете те, которые просто проверяют, что электронная почта является электронной почтой, номера телефонов являются числовыми и не являются бизнес-правилами по своей природе.

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

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

Вот пример

$checkUniqueUserName = new CheckUniqueUserName();
$checkEmailNotUsed = new EmailNotUsed();
$validator = array();
$validator[$checkUniqueUserName->name()] = $checkUniqueUserName;
$validator[$checkEmailNotUsed->name()] = $checkEmailNotUsed;

$results = array();

foreach ($validator as $v)
{

  $result[$v->getValidatorName()] = $v->execute($userInfo);
}

class CheckUniqueUserName()
{

   public function execute($userInfo)
   {
       // SQL blah blah blah

      if ($bNameUnique)
        return array ('success' => 1)
      else
        return array ('success' => 0, 'error' => "$name is in used", 'error_code' => 'duplicate_name);

   }

}

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

Хотя я не совсем уверен, что вы имеете в виду под ответными отзывами.

...