php - modelo - mvc c#

¿El mejor lugar para la validación en el modelo/vista/modelo de controlador?

Question

Estoy trabajando en un proyecto PHP que hace un uso extensivo del patrón de diseño MVC. Estoy buscando agregar validación a un formulario y tengo curiosidad sobre cuál es el lugar correcto para la validación.

Debido a la forma en que se generan los formularios, la validación en los datos de devolución es mucho más simple y menos repetitiva en los componentes de vista. ¿Es aceptable tener la vista validando los datos de respuesta, o debería implementarse dentro del controlador, o incluso el modelo?

¿Cuales son los beneficios?

Answer 1

No se confunda con desinfectar o limpiar el valor publicado con la validación. Debería buscar los valores publicados y eliminarlos eliminando los elementos maliciosos de los valores dentro del controlador. Luego, envíe los datos al Modelo para que sean validados para los valores o formatos esperados. Al dividir esas acciones en dos procedimientos, se reduce el riesgo de implementación de código malicioso. Este método funciona bien si está utilizando la política "no confíe en nadie"; saber que algunos programadores pueden volverse descuidados o flojos. Otro lado positivo es evitar que tu modelo se hinche y se trabaje demasiado, de ser así, utiliza un modelo de ayuda para hacer el trabajo sucio. Este enfoque también ayudará a equilibrar la carga de su aplicación y mejorar el rendimiento.

Answer 2

Si está validando los datos en el lado del cliente (es decir, validación de Javascript) que no es absolutamente suficiente y no es seguro en absoluto, debe implementarlo en la Vista.

Si está validando datos del lado del servidor, y su validación no requiere la lógica de negocios de la aplicación (es decir, no está verificando si el usuario tiene suficiente crédito en su cuenta), debe validar en el controlador.

Si la validación requiere lógica comercial, impleméntela dentro del modelo y llámela a través del controlador.

La validación de devolución de datos no es buena ya que ejerce mucha presión y demora, y la única ventaja es para el programador (no se debe tener en cuenta).

Puede usar expresiones regulares para la mayor parte de la validación, que tiene la misma sintaxis (casi) en PHP y JS.

Answer 3

El lugar correcto para la validación es el Modelo .

Esto tiene más sentido porque está validando los datos, que es lo que representa el modelo. En términos de las actualizaciones de CRUD, el modelo siempre debe usarse de alguna manera.

• Si está cambiando los datos de la vista, debe verificar las validaciones.

• Si tiene controladores que cambian datos, debe verificar las validaciones.

• Y finalmente, si tiene el modelo mismo cambiando datos, aún debe tener validaciones.

La única forma de lograr este estado es hacer que la validación entre en el modelo.

Debido al rendimiento y la respuesta más rápida, después de implementar las validaciones en el modelo, debe intentar agregar algún tipo de cliente (JS) para notificar inmediatamente al usuario final.

La validación es siempre sobre los datos. ¿Por qué estás validando datos? Para que pueda mantener la integridad de la información que almacena. Tener las validaciones a nivel de modelo permite que los datos teóricamente siempre sean correctos. Esto es siempre una necesidad. A partir de ahí, puede agregar validaciones adicionales en su lógica de negocios y en el lado del cliente para hacer que su aplicación sea más fácil de usar.

Answer 4

La validación en el modelo parece ser el enfoque más común (terminas con algo como $obj->isValid() ) y esto es adecuado en muchas situaciones.

Sin embargo, dependiendo de su caso de uso, puede haber buenas razones para realizar la validación fuera del modelo, ya sea usando un código de validación por separado o en el controlador, etc.

• Si gran parte del problema de validación global involucra información no accesible para el modelo (por ejemplo, si un usuario administrador puede realizar transformaciones que un usuario normal no puede realizar, o ciertas propiedades no se pueden cambiar después de una fecha determinada), es posible que desee verificar todas estas restricciones en el mismo lugar.
• También puede ser conveniente o necesario aplicar reglas de validación muy laxas al construir objetos para las pruebas. (Un objeto de "cesta de la compra" normalmente podría requerir un usuario asociado, que a su vez requiere una dirección de correo electrónico válida, etc. Un objeto 100% válido de la cesta de la compra podría ser inconveniente para construir en las pruebas de unidad de la cesta de la compra).
• Por razones históricas, las reglas de validación pueden cambiar (por ejemplo, aplicando un "género" donde previamente no era necesario) y por lo tanto puede terminar con diferentes versiones de datos que deben tratarse de manera diferente. (Diferentes reglas de validación también pueden aplicarse a la importación masiva de datos).
• Si la validación es muy compleja, es posible que desee proporcionar diferentes mensajes de error (o ninguno) según lo que sea más útil para la persona que llama. En otras situaciones, true o false podría ser todo lo que sea necesario.

Es posible manejar estos diferentes casos de uso mediante argumentos al método isValid() del modelo, pero esto se vuelve cada vez más difícil a medida que aumenta el número de estilos de validación. (Y creo que está casi garantizado que un único método de "talla única" isValid() método isValid() resultará insuficiente para la mayoría de los proyectos no triviales).