[OPINION] Lógica de Validación.

[Webstudio]

Cómo están?

Tengo una duda que me generó el estar trabajando con Zend_Form. Es común al crear un formulario con este componente, que se le indique los filtros que se aplicará a los campos y los métodos de validación que sufrirán los mismos... el tema es que esto me genera una duda..

La Lógica de Validación, tenemos que hacerla en el Formulario? o en el mismo Modelo? o en ambos?

Ahora estoy utilizando el acercamiento stándard, de controlar todo en los Forms, y luego trabajar con los datos limpios sobre el modelo, pero me gustaría saber qué opinan ustedes al respecto.

Saludos !

[HackmanC]

Hola,

Hipotéticamente, dependiendo del tipo de aplicación, la validación debería estar segmentada en la base de datos, el acceso a datos, la lógica de negocios y procesos y el modelo; y en el último caso y como valor agregado en la vista, para crear aplicaciones escalables.

Por ejemplo, la corporación XYZ tiene una aplicación diseñada de forma escalable; y en su 'lógica de procesos' dice que solamente se puede emitir cheques el día viernes. La validación se debe realizar en cualquier aplicación de toda la corporación que 'emita cheques'. Si la validación se realiza en el modelo, al 'reutilizar' esos componentes de acceso a datos ya tienen embebido el proceso de validación de la regla de 'emisión de cheques el día viernes'.

Saludos,

ps:

En lenguages como PHP no es tan evidente su utilidad, como en Java donde existen los Enterprise Java Beans, que refuerzan la lógica de procesos a nivel empresarial y/o corporativo.

[Webstudio]

HackmanC, muchas gracias por responder, Este es el tipo de respuesta que estoy buscando para entablar un debate interesante y que nos pueda ayudar a todos.

En mi caso, utilizando ZendFramework, entré de nuevo en el modo "principiante", que necesitado de aprender, toma los "malos ejemplos" de algunos tutoriales (puestos ahi para facilitar el aprendizaje) como verdades absolutas, y realmente no quiero que me pase eso.

Entonces, pensando como si estuviera creando mi propio Framework (como varias veces lo he hecho), caí en que tendríamos que tener la misma lógica de validación desparramada en varias capas:

( MODELO ) <--> ( CAPTURA DE DATOS / SERVER) <--> (CAPTURA DE DATOS / NAVEGADOR)

Entonces, siendo que tenemos que chequear lo mismo, en tres ambientes distintos, como podemos ahorrarnos el hecho de tener que codear TRES veces las mismas comprobaciones. Si fuera vago, diría "dejamos solo en la capa más baja, en el modelo", pero no es lo que me parece mejor.

Qué harían?

[HackmanC]

Hola,

Después de escribir como 4 hojas ... creo que me estaba yendo por otro lado.

Creo que todo depende del tipo de aplicación, por ejemplo, en una vista que tiene 5 campos que van directo a la base de datos, se puede validar los campos, que sean numéricos, una dirección de email, etc.

En una vista con 20 controles o más, que van a actualizar 10 o 20 tablas, no me sirve de mucho validar cada valor, igual puede suceder otro error de cualquier tipo al guardar la información.

En este último caso la validación del lado del cliente lo consideraría como un valor agregado.

Pero esa es solamente mi opinión,
Saludos,

[enriqueplace]

Cada capa debe tener su propia validación, independientemente de la otra capa, pero muchas veces el tema es qué validar.

Todo lo que fuera "lógica de negocio" debería ser responsable el "Modelo", y en la presentación, "Vistas", bien puedes hacer el pedido de información al Modelo: conceptualmente hablando muchos piensan que MVC significa que el controller debe pedir los datos primero al Modelo para pasarlo a la Vista y esto no es correcto.

Por lo tanto, si en el modelo estarán tanto la lógica como la persistencia (que eso no significa que tengas clases que hagan ambas cosas juntas, bien puedes tener una clase Modelo que haga de fachada a clases que sean de lógica y otras de persistencia), puedes pedir desde la vista al modelo sin pasar por el controller la información que necesites.

Si usas Ajax, por cómo funciona el MVC, no te quedará otra que pasar por el controller ya que es una petición del exterior.

Esto no quita que además tengas lógica de negocios en la base de datos, pero eso no significa que debas eliminarlo de todas las demás capas. Que es redundante, sí, que es pesado mantenerlo, sí, pero toda redundancia además de un costo tienen un beneficio (y viceversa) y hay que evaluar los contextos

De todas formas las capas deberían ser independientes, bien podrías evaluar información "genérica" en las capas que no son de dominio y en estas lo más específico, por ejemplo:

1. Pides el email en el form y luego se lo pasa al modelo y la persistencia te lo rebota por no estar bien formado (la validación la haces en una capa)
2. Pides el email en el form y lo validas ahí para no tener que pasar a la persistencia, pero en caso que algo falle en la interfaz esto es controlado también a la hora de persistir.
3. El punto 2 también es útil cuando tienes varias capas de presentación, o cuando decides cambiar la presentación por otra, y así logras que tu sistema se mantenga consistente.

PD: cuando hablo de capas o de dominio/presentación/persistencia no estoy diciendo que MVC sea 3 capas ni que cada uno de los componentes del MVC se correspondan directamente con cada capa, trabajan de forma distintas, pero hay conceptos comunes que se mantienen (capas, responsabilidades, etc, muchas veces agrupados dentro del Modelo).

Saludos

[HackmanC]

Iniciado por enriqueplace

Cada capa debe tener su propia validación, independientemente de la otra capa, pero muchas veces el tema es qué validar ...

Muy buen punto.

Iniciado por enriqueplace

...

1. Pides el email en el form y luego se lo pasa al modelo y la persistencia te lo rebota por no estar bien formado (la validación la haces en una capa)
2. Pides el email en el form y lo validas ahí para no tener que pasar a la persistencia, pero en caso que algo falle en la interfaz esto es controlado también a la hora de persistir.
3. El punto 2 también es útil cuando tienes varias capas de presentación, o cuando decides cambiar la presentación por otra, y así logras que tu sistema se mantenga consistente.

...

El re-utilizar los mismos componentes el proceso de validación se simplifica y se obtiene consistencia y escalabilidad. Y al final no parece tan redundante.

Por ejemplo, para seleccionar 1 de 7 opciones únicas (podría ser 1 día de la semana), en la base de datos se puede crear un rango de 1..7 en ese campo, pero en la vista se muestran 7 imágenes diferentes, que al seleccionar 1 cambia de color.

Al reutilizar el componente no hay que crear la lógica en cada vista, y al mostrar las 7 imágenes la validación no parece redundante, sino mas bien un valor agregado al presentarlo de una forma agradable y fácil de usar.

Es escalable porque se puede modificar el control para que acepte 8 días (es solamente un ejemplo irreal) y cambia automáticamente en todas las vistas con pequeños ajustes.

Y la misma lógica se podría aplicar a número enteros, fechas, listas, arboles, etc., re-utilizando componentes.

En el caso del e-mail si parece horriblemente redundante, pero creo que no hay muchos casos de ese tipo.

Saludos,

[Webstudio]

Quería agradecerles a los dos por sus comentarios. Es justamente el tipo de conversación que me interesaba que se genere en torno a este tema. Las cosas quedan un poco más claras a partir de ahora.

Estoy buscando y repensando la mejor manera de utilizar los componentes que nos deja Zend Framework. Si bien ahora por el apuro no los estoy utilizando de la manera que me gustaría (mis modelos heredan directamente de Zend_Db_Table_Abstract) si estoy buscando la mejor forma de establecer mis Objetos de datos (DTO), y relacionarlos con Mappers y Gateways de persistencia.

Me queda aún repensar el tema de la validación. Si bien la validación de las reglas de negocio, concuerdo 100% en que debe realizarse en el modelo, yo estoy pensando en un sistema bastante más automatizado en el cual el DTO a la vez, conoce el formulario que tiene que desplegar para "renderizarse" al crear o editar un campo.

Todo esto es porque quisiera trabajar en algún sistema de Scaffolding para Zend Framework, donde nosotros definamos la estructura de nuestro modelo (ya sea utilizando algún soft como Mysql Workbench) en un XML, y leyendo eso, creemos un Modulo (con sus controllers + actions), DTOs, Mappers, Gateways, etc... vamos, como lo que tienen en Rails y otros Frameworks en general.

Y si pudiera utilizar Zend_Tool para esto, sería aún más feliz.

[HackmanC]

Hola,

Iniciado por Webstudio

... yo estoy pensando en un sistema bastante más automatizado en el cual el DTO a la vez, conoce el formulario que tiene que desplegar para "renderizarse" al crear o editar un campo. ...

El modelo debe ser completamente independiente de la vista. El modelo no debería saber como se va a desplegar, inclusive el modelo se debería poder desplegar en 2, 3 o N vistas diferentes al mismo tiempo. (Según el concepto original de MVC, observador/observable). (Es decir un campo fecha se podría desplegar en un text y un calendario en la misma 'ventana').

Iniciado por Webstudio

... Todo esto es porque quisiera trabajar en algún sistema de Scaffolding para Zend Framework, ...

Sería muy interesante (útil) que lograras desarrollar esa herramienta en PHP.

Saludos,

ps:

En lo personal divido la vista en 4 áreas importantes, Fundation, encapsula los controles básicos del lenguaje (a veces parece redundante). Framework, encapsula controles más avanzados, como por ejemplo, me gustan las etiquetas alineadas a la derecha siempre, así que tengo un control que se llama LabelAlignRight. Library, encapsula las controles avanzados, como el Calendario y un TreeView con fotos para seleccionar clientes o empleados de nómina, y Views, los formularios que usan los controles anteriores.

Y reutilizo los componentes, aunque intento que los componentes sean genéricos, muchas veces aceptan un DTO específico (por lo cual mis vistas son dependientes del modelo, aunque no es obligatorio, como las Tablas <table>).

[Webstudio]

A lo que me refiero de que el modelo "conozca como renderizarse", me refiero a:

El modelo en su mayoría será auto-generado por código a partir de una definición de tablas, así como también se auto-genere un objeto Zend_Form (o derivado) con los campos y los Validators necesarios para poder validar el DTO al momento de cargarlo con datos. Y de ser necesario, contar con una manera rápida y directa para crear un CRUD.

Me gustaría poder comenzar a jugar con UML para ir pensando el sistema.

[HackmanC]

Je, je .. perdón ... mi error. Yo entendí otra cosa.
Saludos,