La validación de entrada de datos siempre fue una lucha interna para mí.
A punto de agregar un marco de seguridad real y un código a nuestro proyecto de reescritura de aplicaciones heredadas (que hasta ahora mantiene el código de seguridad heredado y la validación de datos heredados), me pregunto nuevamente cuánto debería validar, donde, etc.
Durante mis 5 años como desarrollador profesional de Java, creé y perfeccioné mis reglas personales para la validación de entrada de datos y medidas de seguridad. Como me gusta mejorar mis métodos, me gustaría que algunos escuchen algunas ideas de ustedes. Las reglas y procedimientos generales están bien, y los específicos de Java también.
En resumen, estas son mis pautas (expuestas en un estilo de aplicación web de 3 niveles), con breves explicaciones:
1.o nivel del lado del cliente (navegador): validación mínima, solo reglas invariables (campo de correo electrónico obligatorio, debe seleccionar un elemento y similares); uso de validación adicional como "entre 6 y 20 caracteres" menos frecuente, ya que esto aumenta el trabajo de mantenimiento en los cambios (se puede agregar una vez que el código comercial es estable);
Lado del servidor de primer nivel (manejo de comunicación web, "controladores"): no tengo una regla para este, pero creo que solo se deben manejar aquí los errores de manipulación de datos y ensamblaje / análisis (el campo de cumpleaños no es una fecha válida); agregar más validación aquí fácilmente lo convierte en un proceso realmente aburrido;
2do nivel (capa empresarial): validación sólida como una roca, nada menos; formato de datos de entrada, rangos, valores, verificación interna del estado si el método no se puede llamar en cualquier momento, roles / permisos del usuario, etc. use la menor cantidad posible de datos de entrada del usuario, recupere nuevamente de la base de datos si es necesario; si consideramos también los datos recuperados de la base de datos como entrada, solo los validaría si se sabe que algunos datos específicos no son confiables o están lo suficientemente corruptos en la base de datos: la escritura fuerte hace la mayor parte del trabajo aquí, en mi humilde opinión;
3er nivel (capa de datos / DAL / DAO): nunca creí que se necesitara mucha validación aquí, ya que solo se supone que la capa empresarial tiene acceso a los datos (validar quizás en algún caso como "param2 no debe ser nulo si param1 es verdadero"); observe, sin embargo, que cuando me refiero a "aquí" me refiero a "código que accede a la base de datos" o "métodos de ejecución de SQL", la base de datos en sí es completamente lo contrario;
la base de datos (modelo de datos): debe ser tan bien pensada, fuerte y autoejecutable como para evitar datos incorrectos y corruptos en la base de datos tanto como sea posible, con buenas claves primarias, claves externas, restricciones, tipo / longitud / tamaño de datos / precisión y así sucesivamente: estoy dejando de lado los desencadenantes, ya que tienen su propia discusión privada.
Sé que la validación de datos temprana es buena y en cuanto al rendimiento, pero la validación de datos repetida es un proceso aburrido, y admito que la validación de datos en sí misma es bastante molesta. Es por eso que tantos codificadores lo omiten o lo hacen a mitad de camino. Además, cada validación duplicada es un posible error si no están sincronizados todo el tiempo. Esas son las principales razones por las que hoy en día prefiero dejar que la mayoría de las validaciones lleguen a la capa empresarial, a expensas del tiempo, el ancho de banda y la CPU, excepciones manejadas caso por caso.
Entonces, ¿qué piensas sobre esto? Opiniones opuestas? ¿Tienes otros procedimientos? ¿Una referencia a ese tema? Cualquier contribución es válida.
Nota: si está pensando en la manera Java de hacer las cosas, nuestra aplicación está basada en Spring con Spring MVC y MyBatis (el rendimiento y el modelo de base de datos incorrecto descartan las soluciones ORM); Planeo agregar Spring Security como nuestro proveedor de seguridad más JSR 303 (¿Validador de Hibernación?)
¡Gracias!
Editar: algunas aclaraciones adicionales en la tercera capa.