¿Dónde haces tu validación? modelo, controlador o vista
https://stackoverflow.com/questions/134388
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Dónde coloca la validación de entrada de usuario en una aplicación de formulario web?
- Vista: lado del cliente de JavaScript
- Controlador: idioma del lado del servidor (C # ...)
- Modelo: Base de datos (procedimientos almacenados o dependencias)
Creo que hay una validación requerida por cada nivel:
- ¿El usuario ingresó un valor sano?
- son fechas, fechas reales, son números, números reales ...
- Haga de nuevo todas las comprobaciones en 1. además de las comprobaciones de ataques maliciosos (IE XSS o inyección de SQL)
- Las comprobaciones realizadas en 1. son principalmente para evitar un viaje de ida y vuelta al servidor cuando el usuario comete un error.
- Ya que se realizan en el lado del cliente en javascript, no puede confiar en que se ejecutaron. La validación de estos valores nuevamente detendrá algunos ataques maliciosos.
- ¿Se cumplen las dependencias (es decir, si el usuario agregó un comentario a una pregunta válida)?
- Una buena interfaz hace que estos sean muy difíciles de violar. Si algo queda atrapado aquí, algo salió muy mal.
[inspirado por esta respuesta ]
Solución
Verifico todos los niveles, pero me gustaría observar un truco de validación que utilizo.
Valido en la capa de la base de datos, las restricciones adecuadas en su modelo proporcionarán la validación automática de la integridad de los datos.
Este es un arte que parece estar perdido en la mayoría de los programadores web.
Otros consejos
Validación en el modelo, rutinas opcionalmente automatizadas en la interfaz de usuario que toman sus sugerencias del modelo y mejoran la experiencia del usuario.
Por rutinas automatizadas quiero decir que no debería haber ningún código de validación por modelo en la interfaz de usuario. Si tiene una biblioteca de métodos de validación, como RoR's (que tiene métodos como validates_presence_of: username), el controlador o la vista deben poder leerlos y aplicar métodos javascript equivalentes (o lo que sea conveniente).
Eso significa que tendrá que duplicar la biblioteca de validación completa en la interfaz de usuario, o al menos proporcionar un mapeo si usa uno preexistente. Pero una vez hecho esto, no tendrá que escribir ninguna lógica de validación fuera del modelo.
La validación se puede realizar en todas las capas.
La validación de la entrada de un formulario web (todas las cadenas, la conversión a los tipos adecuados, etc.) es diferente de la validación de la entrada de un servicio web, archivo XML, etc. Cada uno tiene sus propios casos especiales. Por supuesto, puede crear una clase de ayudante de Validador, externalizando así la Validación y permitiendo que las vistas la compartan.
Luego tiene la validación de la capa DAO: ¿hay suficientes datos en el modelo para persistir (para no cumplir con restricciones nulas, etc.) y así sucesivamente? Incluso puede tener restricciones de verificación en la base de datos (es el estado en ('N', 'A', 'S', 'D'), etc.).
Esto es interesante. Durante mucho tiempo realicé toda la validación en el modelo, justo encima de lo que consideraría DAL (capa de acceso a datos). Por lo general, mis modelos tienen un patrón después de la puerta de enlace de datos de tabla con un DAL que proporciona la abstracción y la API de bajo nivel.
En el lado del TDG, implementaría la lógica de negocios y las validaciones, como:
- El nombre de usuario está vacío
- es el nombre de usuario > 30 caracteres
- Si el registro no existe, devuelve un error
A medida que mi aplicación crecía en complejidad, comencé a darme cuenta de que gran parte de la validación podía realizarse en el lado del cliente, utilizando JavaScript. Así que reformulé la mayor parte de la lógica de validación en JS y limpié mis modelos.
Luego me di cuenta de que la validación del lado del servidor (no filtrar / escapar, lo que considero diferente) debería realizarse probablemente en el servidor y solo del lado del cliente como la guinda del pastel.
Entonces, cuando volví a darme cuenta de la lógica de validación, probablemente existía una diferencia clara entre la validación / afirmación de ENTRADA y la lógica / reglas de negocios.
Básicamente, si se puede hacer en el lado del cliente de la aplicación (usando JS), considero que esto es una validación de ENTRADA ... si el modelo DEBE hacerlo (¿ya existe este registro, etc.?) Consideraría esa lógica empresarial. Lo que es confuso es que ambos protegen la integridad del modelo de datos.
Si no validas la longitud de un nombre de usuario, ¿qué impide que las personas creen un nombre de usuario de un solo carácter?
Todavía no he decidido por completo dónde colocar esa lógica a continuación, creo que realmente depende de lo que más le guste, controladores delgados, modelos pesados ??o viceversa ...
En mi caso, los controladores tienden a estar mucho más centrados en la aplicación, mientras que los modelos, si se diseñan con cuidado, a menudo se pueden reutilizar en " otro " Los proyectos no solo son internos, así que prefiero mantener los modelos livianos y los controladores en el lado más pesado.
Las fuerzas que te guían en cualquier dirección son opiniones, requisitos, experiencias, etc., realmente personales.
Tema interesante :)
La validación debe hacerse en el controlador, es el único lugar que garantiza la seguridad y la respuesta.
La validación debe hacerse en la vista: es el punto de contacto, proporcionará el mejor UE y le ahorrará trabajo extra al servidor.
La validación se realizará en el modelo, pero solo para un cierto nivel central de controles. Las bases de datos siempre deben reflejar las restricciones apropiadas, pero es ineficiente dejar que esto represente una validación real, y no siempre es posible que una base de datos determine una entrada válida con restricciones simples.
Toda la validación debe suceder al menos una vez, y esto debe estar en el nivel medio, ya sea en sus objetos de valor (en el sentido de DDD, no debe confundirse con los DTO), o a través del objeto comercial de la entidad sí mismo. La validación del lado del cliente puede ocurrir para mejorar la experiencia del usuario. Tiendo a no hacer la validación del lado del cliente, porque solo puedo exponer todas las cosas que están mal en el formulario a la vez, pero eso es solo mi preferencia personal La validación de la base de datos puede ocurrir para asegurar la integridad de los datos en caso de que arruine la lógica El nivel intermedio o posterior terminó algo.
Solo lo hago en la Vista y el Controlador, la base de datos aplica algo de eso por sus tipos de datos y otras cosas, pero prefiero que no llegue tan lejos sin que detecte un error.
Sin embargo, lo que es importante saber es que nunca puedes confiar en la vista, aunque esa es la forma más fácil de dar comentarios al usuario, por lo que debes desinfectar al menos un nivel más.Hmmmm, no estoy seguro. Habría dicho el controlador hasta que leí este artículo con respecto a: Controladores flacos, modelos gordos
Dado que la mayoría de las validaciones dependen de reglas de negocio , hago la validación en la capa de negocios como clases de herramientas de terceros. Hay otros tipos de validaciones, como la entrada del usuario, mientras que debe hacerse en el controlador, pero también puede encapsular esas reglas de validación en clases de terceros. En realidad, depende de qué validar.
Las validaciones del lado del cliente son las secundarias, solo se hacen para construir una validación de entrada ligera, pero la validación del lado del servidor es necesaria siempre . Nunca puedes confiar en la entrada del usuario;)
.NET tiene buenos controles para crear validaciones, pero business layer siempre necesita un mejor enfoque para validar los datos y esos controles no son suficientes para esa tarea.
Validación de entrada simple en la vista. Validación completa en el modelo. ¿Razón? Si cambia la tecnología de vista y la validación se encuentra en la vista / controlador, debe volver a escribir su validación para la nueva vista. Esto puede introducir errores. Póngalo en el modelo, y todas las vistas lo reutilizarán ...
Pero, como dije, validación simple en la vista para velocidad y facilidad.
