Каков хороший подход к работе с повторяющимися и длинными кодами проверки?

Question

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

<Ол>

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

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

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

Answer 1

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

Answer 2

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

$form->isValid($data);

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

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

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

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

Answer 3

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

Идея состоит в том, чтобы иметь каждый код бизнес-правила в качестве функтора - если это 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);

   }

}

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

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