software - lucidchart database diagram
Mantener la lógica de validación sincronizada entre los lados del servidor y del cliente (4)
En mi pregunta anterior, la mayoría de los comentaristas estuvieron de acuerdo en que tener una lógica de validación tanto en el lado del cliente como del servidor es algo bueno.
Sin embargo, hay un problema: debe mantener sus reglas de validación sincronizadas entre la base de datos y el código del cliente.
Entonces la pregunta es ¿cómo podemos lidiar con eso?
Un enfoque es usar técnicas de ORM, las herramientas de ORM modernas pueden producir código que pueda encargarse de la validación de datos antes de enviarlo al servidor.
Estoy interesado en escuchar tus opiniones
¿Tienes algún tipo de proceso estándar para lidiar con este problema? ¿O tal vez piensas que esto no es un problema en absoluto? :)
EDITAR :
Chicos, antes que nada, gracias por sus respuestas.
Mañana resumiré sus respuestas y actualizaré el texto de la pregunta como en este caso
Algunos frameworks proporcionan un soporte de validación que puede mantener la validación de su cliente y servidor sincronizada. Eche un vistazo a este tutorial de validación de costura usando anotaciones. Es una buena implementación y muy fácil de entender.
De todos modos, si no quieres confiar en frameworks, creo que es fácil implementar algo similar.
Como se menciona en una de las respuestas a la otra publicación, si va a mantener sus capas separadas, no hay una buena manera de evitar la duplicación de la lógica de validación en cada capa. Si usa algo para unirlos automáticamente, ha introducido una especie de acoplamiento entre las capas que podría obstaculizarlo en el futuro. Este podría ser uno de esos casos en los que solo debe hacer un seguimiento de las cosas manualmente.
Independientemente de cómo lo haga, debe asegurarse de que cada capa haga su propia validación, porque nunca se sabe cómo se va a acceder a esa capa. No hay garantía de que todas las capas que implementen permanezcan siempre juntas.
Me gusta usar un servicio de validación, que no necesariamente se preocupa por el origen de los datos que se validarán. Esto puede funcionar de diferentes maneras cuando se llega a la parte sobre la transmisión de reglas de validación a un cliente (es decir, una página web), pero creo que el aspecto más importante de esto es tener una autoridad única para las reglas de validación reales.
Por ejemplo, si tiene una lógica de validación en sus entidades centrales de datos, como una colección de objetos de ValidationRule que se controlan mediante un método Validate, un escenario muy típico, promocionaría esas mismas reglas para el cliente (javascript) a través de una transformación.
En el mundo ASP.NET (el único con el que puedo hablar) hay un par de formas de hacerlo. Mi método preferido consiste en crear validadores personalizados que se relacionen con sus widgets UI a campos (y todas sus reglas de validación) en sus entidades. La ventaja de esto es que toda su lógica de validación se puede agrupar en un solo validador. La desventaja es que sus mensajes de validación se volverán densos, ya que las reglas de validación se prueban todas a la vez. Esto puede, por supuesto, mitigarse haciendo que su lógica de validación devuelva solo una mención de la primera falla, etc.
Esta respuesta probablemente suena algo nebulosa e inespecífica, pero los dos puntos que me gustaría hacer son:
- La validación debe ocurrir lo más cerca posible de los puntos donde se ingresan los datos y dónde se han comprometido.
- Las mismas reglas de validación deben usarse dondequiera que se produzca la validación: si se aprueba la validación del lado del cliente, entonces nunca debe fallar la validación más adelante (reglas comerciales previas a la grabación, violación de la clave externa, etc.)
Si usa ASP.Net, puede usar una serie de controles de validación. Estos controles están escritos de una manera muy genérica, de modo que la mayoría de ellos duplican automáticamente su lógica de validación entre el cliente y el servidor, aunque solo establezca opciones para el control en un solo lugar.
También puede heredar de ellos para crear validadores específicos de dominio adicionales, y hay paquetes de control de terceros en la web que puede obtener y agregar a los controles de base.
Incluso si no está utilizando ASP.Net, vale la pena echar un vistazo a cómo se hace esto. Le dará ideas sobre cómo hacer algo similar en su propia plataforma.