¿Cuál es un buen enfoque para lidiar con códigos de validación repetitivos y largos?

Question

Hace poco comencé la programación web y estoy bastante sorprendido de que, aunque estoy usando una biblioteca de validación, sigo obteniendo 20-30 líneas de código solo para la validación, sin contar los mensajes de error y las funciones de devolución de llamada. Estoy usando el framework Kohana MVC y me preguntaba si habría alguna forma de acortar mis códigos de validación. Traté de pensar en lo siguiente

1. poner códigos de validación en mi modelo (que es bastante necesario para un novato como yo).
2. crear una biblioteca realmente pequeña para validar entradas (algo que se engancha a la clase de validación, lo que me permite llamar a la biblioteca para procedimientos repetitivos como registro de usuario, edición y otras cosas)

¿O hay formas mejores y más eficientes?

Answer 1

Recomiendo encarecidamente trabajar para incluir la validación en el modelo. Una vez que pueda hacer uno, cualquier otro que cree será mucho más fácil. Además, si tiene varios controladores tratando de guardar esos datos, no necesitará volver a codificar la validación. Los documentos de Kohana contienen algunos ejemplos para integrar la biblioteca de validación y ORM, debe comenzar allí.

Answer 2

Uso Zend_Validate con Zend_Forms para la validación en la que el código de validación está en el método init de formularios. Todo lo que tengo que hacer es pasar una serie de validadores para cada elemento y luego ejecutar ..

$form->isValid($data);

... fuera del formulario para validar los datos.

La matriz de validación es fácilmente más de 30 líneas porque separo cada entrada de matriz con una nueva línea. Pero supongo que tendrá eso si define las reglas de validación de grano fino para cada elemento correctamente.

Y es realmente fácil definir nuevos Validadores en Zend.

editar: descubrí un marco que amplía el Marco Zend que permite que los objetos de dominio contengan su propia validación. Se llama marco Xyster, pero no pude hacerlo funcionar en el primer intento, así que no lo he intentado después de eso.

Answer 3

Aquí está mi estrategia para lidiar con el código de validación. Supongo que por 'biblioteca de validación', se refiere a aquellos que solo se aseguran de que un correo electrónico sea un correo electrónico, que los números de teléfono sean numéricos y no sean reglas de naturaleza comercial.

La idea es tener cada código de regla de negocio como un functor: si es PHP, puede obtenerlo simplemente usando una cadena para definir la función; para otros idiomas, puede que tenga que usar el patrón de estrategia. Defina una interfaz para el functor (no es necesario para PHP) y vuélvala a una matriz.

Ejecute la matriz que devolverá el éxito, el error y un código de error a un búfer. Al final, examine el búfer de error y determine qué validación ha fallado. Úselo para personalizar la vista.

Aquí hay un ejemplo

$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);

   }

}

Al final, tendrá una matriz de resultados, cada uno con un proceso de validación, y sabrá cuál ha fallado y cuál no. Esto se puede pasar al lado del cliente para su posterior procesamiento, como resaltar los campos fallidos. El error_code se puede usar para buscar el mensaje de error y el formato correctos aplicados.

Sin embargo, no estoy muy seguro de lo que quieres decir con devoluciones de llamada.