Práctica recomendada para validar datos de entrada para aplicaciones de varios niveles

Question

En nuestra aplicación tenemos varias capas. Capa de servicio, capa DAO y acciones (aplicaciones de struts).

Los datos pasan de una capa a otra capa.

¿Dónde idealmente deberíamos colocar la validación de entrada?

Digamos, ID de usuario, el número de teléfono proviene de la interfaz de usuario, son obligatorios. Entonces ya estamos haciendo la validación en el lado del cliente.

Ahora, según mi opinión, esta todo lo que necesita. En ningún otro lugar debe ser validado.

Pero uno de mis colegas argumenta, ¿qué pasa si el cliente hace la solicitud directamente. Entonces, necesitamos agregar acciones también.

ahora, en Dao, así, el mismo método se acostumbrarse a alguna otra acción y THT no tiene validación,

o, por ejemplo capa de servicio, podría ser expuesto como, por ejemplo como servicio web, por lo que también deberías tener validación.

Así que esencialmente, Él está sugiriendo ... debemos tener validaciones en todas partes. Lo cual no tiene sentido para mí. Su duplicación a través de la capa.

¿Cuál es el enfoque ideal para esto? Digamos que la validación es de simple verificación nula o alguna validación compleja.

Answer 1

De acuerdo con Pangea, definitivamente debe tener validaciones en los puntos finales del cliente y del servicio.

Me gustaría añadir que el concepto de validaciones es "fail-fast". Agregue validaciones a cada capa para que el usuario o la persona que llama recibirán comentarios inmediatos sobre por qué fallaría la llamada en lugar de potencialmente iniciar una transacción, realizar consultas complejas y escribir solo para encontrar que un campo es demasiado corto.

En el lado del cliente, desea tanta validación como sea posible para no perder el tiempo del usuario, el ancho de banda y los recursos del lado del servidor (que en muchos casos tienen conflictos). Sin embargo, generalmente no puede hacer todas las validaciones en el lado del cliente (por ejemplo, para verificar si ya hay dicho nombre de usuario en uso al registrarse) por lo que querría que se revisara y que se devuelva un mensaje de error apropiado tan pronto como golpea la capa de servicio.

En la capa del servidor, debe suponer que todas las entradas son potencialmente peligrosas e incorrectas (y muchas veces lo serán). De hecho, creo que es mejor ser más comprensivo y agresivo al validar las entradas en la capa de servicio ya que esa es su última línea de defensa. Si omite una validación o dos en el lado del cliente, solo necesita un buen mecanismo de manejo de fallas para que los usuarios sepan lo que está mal. Si pierde algo en el lado del servicio y se produce un desastre, podría significar horas o días de depuración e intentar restaurar las copias de seguridad de la base de datos.

También se realizan algunas comprobaciones a nivel de la base de datos que imponen aspectos como la integridad referencial y demás. Por lo general, intento tanto como sea posible para buscarlos antes de intentar escribir, ya que interpretar varios mensajes de error de RDBMS y tratar de convertirlos de nuevo a jerga comprensible por el usuario a menudo es difícil, si no imposible.

Answer 2

Si su aplicación proporciona puntos de entrada múltiples (UI o sistema a interfaces de sistema o sistemas por lotes), debe limpiar (comprobaciones nulas, verificaciones de formato, requisitos necesarios, etc.) sus datos en todos estos bordes y antes de alcanza la capa de servicio. Pero esto no significa que deba replicar su lógica de validación. Puede usar marcos que le permitan centralizar su validación. Algunos ejemplos de marcos de validación se pueden encontrar en este post.

Sin embargo, existen validaciones comerciales que deberían pertenecer a su capa de dominio y deben permanecer en la capa de servicio de su dominio u objetos de dominio.

No estoy de acuerdo con que deba realizar la validación en DAO. Los DAO deberían ser responsables de las operaciones CRUD. Si están haciendo más, entonces tienes capas con goteras. Si tiene que procesar cosas en lote, entonces debe asegurarse de que el lote pase por la capa de servicio para que su lote también esté pasando por las mismas validaciones.

Answer 3

La única sabiduría que puedo agregar a la conversación es, nunca confío en el cliente. Ya sea que su cliente esté en HTML, Flash/Flex, o lo que sea, existe la posibilidad de que alguien lo piratee e intente hacer algo que usted no quiere que haga. El seguimiento aquí es, si existe la posibilidad de que alguien vaya a piratearlo, nosotros, como ingenieros de software, debemos suponer que se va a piratear, por lo que, si bien los controles en la interfaz son buenos, y pueden ayudar en la usabilidad de las aplicaciones. , DEBE validar todas sus entradas en el back-end, incluso si eso conduce a duplicar cheques.