asp.net-mvc - una - mvc submit button action
¿Dónde haces tu validación? modelo, controlador o vista (10)
Como la mayoría de las validaciones dependen de las reglas comerciales , realizo la validación en la capa empresarial como clases de herramientas de terceros. Hay otros tipos de validaciones, como la entrada del usuario, mientras que debe realizarse en el controlador, pero también puede encapsular esas reglas de validación en clases de terceros. Realmente, depende de qué validar.
Las validaciones del lado del cliente son las menores, solo hechas para construir una validación de entrada liviana, pero siempre se requiere la validación del lado del servidor. Usted nunca puede confiar en la entrada del usuario;)
.NET tiene buenos controles para crear validaciones, pero la capa de negocios siempre necesita un mejor enfoque para validar los datos y esos controles no son suficientes para esa tarea.
¿Dónde pones la validación de entrada del 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 razonable?
- son fechas fechas reales, son números números reales ...
- Realice todas las comprobaciones en 1. de nuevo y compruebe si hay ataques maliciosos (IE XSS o inyección SQL)
- Las comprobaciones realizadas en 1. son principalmente para evitar un servidor de ida y vuelta cuando el usuario comete un error.
- Como están hechos 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, el usuario agregó un comentario a una pregunta válida)?
- Una buena interfaz hace que sea muy difícil de violar. Si algo está atrapado aquí, algo salió muy mal.
[inspirado por esta respuesta ]
Esto es interesante. Durante mucho tiempo, realicé todas las validaciones en el modelo, justo encima de lo que consideraría DAL (capa de acceso a datos). Mis modelos suelen ser de patrón después de la entrada de datos de tabla con un DAL que proporciona la abstracción y la API de bajo nivel.
Además del TDG, implementaría la lógica comercial y las validaciones, tales como:
- Está vacío el nombre de usuario
- Es nombre de usuario> 30 caracteres
- Si el registro no existe, devuelve un error
A medida que mi aplicación creció en complejidad, comencé a darme cuenta de que gran parte de la validación se podía hacer en el lado del cliente, usando JavaScript. Así que reorganicé la mayoría 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 (sin filtrar / escapar, que considero diferente) debería hacerse también en el servidor y solo el lado del cliente como la guinda del pastel.
Así que la lógica de validación volvió, cuando me di cuenta de nuevo, de que probablemente había una clara diferencia entre la validación / aserción de INPUT y las reglas / lógica de negocios.
Básicamente, si se puede hacer en el lado del cliente de la aplicación (usando JS), considero que esto es validación de ENTRADA ... si DEBE hacerlo el modelo (¿este registro ya existe, etc.?) Entonces consideraría que lógica de negocios. Lo que es confuso es que ambos protegen la integridad del modelo de datos.
Si no valida la longitud de un nombre de usuario, ¿qué impide que las personas creen un único nombre de usuario?
Todavía no he decidido por completo dónde poner esa lógica a continuación, creo que realmente depende de lo que prefiera, controladores delgados, modelos pesados o viceversa ...
Los controladores en mi caso tienden a ser mucho más centrados en la aplicación, mientras que los modelos, si se fabrican con cuidado, a menudo puedo reutilizarlos en "otros" proyectos no solo internamente, así que prefiero mantener los modelos ligeros y los controladores en el lado más pesado.
Las fuerzas que lo impulsan en cualquier dirección son realmente opiniones personales, requisitos, experiencias, etc.
Materia interesante :)
Hmmmm, no estoy seguro Hubiera dicho el controlador hasta que leí este artículo sobre controladores delgados, modelos gordos
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 y proporcionará el mejor UE y ahorrará trabajo adicional a su servidor.
La validación se realizará en el modelo, pero solo para un cierto nivel básico de controles. Las bases de datos siempre deben reflejar las limitaciones apropiadas, pero es ineficiente dejar que esto valga la validación real, ni siempre es posible que una base de datos determine una entrada válida con restricciones simples.
La validación se puede hacer en todas las capas.
Validar la entrada desde un formulario web (todas las cadenas, conversión a los tipos adecuados, etc.) es diferente de validar la entrada de un servicio web, o archivo XML, etc. Cada uno tiene sus propios casos especiales. Puede crear una clase de ayuda de Validator, por lo tanto, externalizar la Validación y permitir que las vistas la compartan.
Luego tiene la validación de la capa DAO: ¿hay suficientes datos en el modelo para persistir (para cumplir con restricciones no nulas, etc.) y demás? Incluso puede tener restricciones de verificación en la base de datos (es estado en (''N'', ''A'', ''S'', ''D'') etc.).
Reviso todos los niveles, pero me gustaría señalar un truco de validación que uso.
Valido en la capa de la base de datos, las restricciones adecuadas en su modelo proporcionarán validación automática de integridad de datos.
Este es un arte que parece estar perdido en la mayoría de los programadores web.
Solo lo hago en la Vista y el Controlador, la base de datos impone algo de eso según sus tipos de datos y otras cosas, pero prefiero que no llegue tan lejos sin que encuentre un error.
Sin embargo, usted respondió bastante su propia pregunta, lo importante es saber que nunca puede confiar en la vista, aunque esa es la ruta más fácil para dar retroalimentación al usuario, por lo que debe desinfectar al menos un nivel más.
Toda validación debe ocurrir al menos una vez, y debe estar en el nivel medio, ya sea en sus objetos de valor (en el sentido DDD, que no debe confundirse con los DTO), o a través del objeto comercial de la entidad misma. 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 puedo exponer todas las cosas que están mal en el formulario a la vez, pero esa 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 se equivoque. el nivel medio o atrás terminó algo.
Validación de entrada simple en la vista. Validación completa en el modelo. ¿Razón? Si cambia su tecnología de visualización y la validación está en la vista / controlador, debe volver a escribir su validación para la nueva vista. Esto puede presentar errores. Póngalo en el modelo, y esto es reutilizado por todas las vistas ...
Pero, como dije, validación simple en la vista para mayor velocidad y facilidad.
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 debe 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 (que tiene métodos como validates_presence_of: username), el controlador o la vista debería poder leerlos y aplicar métodos equivalentes de javascript (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 una asignación si utiliza una biblioteca preexistente. Pero una vez hecho esto, no tendrá que escribir ninguna lógica de validación fuera del modelo.