¿La vista no debe realizar la validación?

Estaba leyendo " En MVC, ¿debería un modelo manejar la validación? " Porque tenía curiosidad acerca de dónde debería ir la lógica de validación en un sitio web de MVC. Una línea en la respuesta superior dice así: "los controladores deben manejar la validación, los modelos deben manejar la verificación".

Me gustó eso, pero me dejó preguntándome por qué no haríamos la validación de datos en la Vista, por varias razones:

1. Las vistas suelen tener un sólido soporte de validación (bibliotecas JS, etiquetas HTML5)
2. Las vistas pueden validarse localmente, lo que reduce la IO de la red
3. La interfaz de usuario ya está diseñada con el tipo de datos en mente (calendarios para fechas, hiladores para números), lo que lo convierte en un pequeño paso desde la validación

Validar en más de un lugar es contrario al concepto de MVC de aislar responsabilidades, por lo que "hacerlo en ambos" parece inapropiado. ¿La validación de datos solo en el controlador es realmente el enfoque dominante?

No creo que haya un solo lugar donde puedas decir que toda la validación debería ir. Esto se debe a que tenemos algunas estrategias de programación diferentes que trabajan juntas en un sitio web estándar de asp.net mvc.

En primer lugar, tenemos la idea de separar la lógica de dominio en modelos, la lógica de 'acción' en controladores y la visualización en una vista. Esto se basa en la idea de que toda la lógica tendrá lugar en el servidor con el navegador simplemente proporcionando una representación de la vista.

Luego, ampliamos la Vista usando javascript del lado del cliente. Esto es tan avanzado en estos días que la idea de 'sitio web de una página' con Jquery / knockout / angular es una práctica común.

Esta práctica puede ser equivalente a escribir una aplicación completa del lado del cliente que implementa un patrón MVC o MVVM. Denigramos la vista a un objeto de transferencia de datos y el controlador a un punto final de servicio. Mover toda la lógica empresarial y de la interfaz de usuario al cliente.

Esto puede brindar una mejor experiencia de usuario, pero tiene que confiar en un cliente esencialmente no confiable. Por lo tanto, aún debe llevar a cabo la lógica de validación en el servidor, independientemente de qué tan bien su cliente valide previamente sus solicitudes.

Además, a menudo tenemos requisitos de validación que el cliente no puede llevar a cabo. p.ej. '¿es único mi nuevo ID?'

Cualquier aplicación que cree con el objetivo de brindar la mejor experiencia / rendimiento necesariamente tomará prestados para múltiples paradigmas de programación y los comprometerá para lograr su objetivo.

Validar en más de un lugar es contrario al concepto de MVC de aislar responsabilidades, por lo que "hacerlo en ambos" parece inapropiado.

¿Podría haber múltiples responsabilidades de validación para considerar aquí? Como dijiste en tu # 3:

La interfaz de usuario ya está diseñada con el tipo de datos en mente (calendarios para fechas, hiladores para números), lo que lo convierte en un pequeño paso desde la validación

Entonces tal vez sea:

Ver : Validar tipo de entrada, formato, requisito ... validación básica de entrada del usuario que no tiene nada que ver con la lógica empresarial. Capture todas estas cosas esponjosas antes de que generemos tráfico de red al hacer una solicitud al servidor.

Modelo : Validar las preocupaciones comerciales de los datos. ¿Es ese un valor legal de acuerdo con las normas comerciales? Sí, es un valor numérico (lo aseguramos en la vista), pero ¿tiene sentido?

Solo un pensamiento.

Voy a suponer que necesita validación para la persistencia.

No solo View, sino que Model tampoco debe manejar la validación. Durante mis días en TI me di cuenta de que DDD es una de las formas de garantizar que realmente estás haciendo las cosas correctamente, es decir. las clases son realmente responsables de lo que deberían ser.

Al seguir el diseño impulsado por dominio, sus modelos incluyen su lógica de negocios, y eso es todo. Pero no incluyen validación, ¿por qué no?

Supongamos que ya está tan lejos que está utilizando en Data Mapperlugar de Active Recordpersistir en su capa de dominio. Pero aún así, desea que los modelos se validen, por lo que agrega la validación a su Modelo.

interface Validation
{
    public function validate();
}

class ConcreteModel extends MyModel implements Validation
{
    public function validate() { // the validation logic goes here }
}

La lógica de validación garantiza que puede insertar correctamente el modelo en su base de datos MySQL ... Pasan unos meses y decide, quiere almacenar sus Modelos en bases de datos noSQL también, bases de datos, que requieren reglas de validación diferentes a MySQL.

Pero tiene un problema, solo tiene 1 método de validación, pero necesita validar a Modelde 2 maneras diferentes.

Los modelos deben hacer lo que son responsables de hacer , deben cuidar su lógica comercial y hacerlo bien. La validación está vinculada a la persistencia, no a la lógica empresarial, por lo tanto, la validación no pertenece a un modelo .

En Validatorsu lugar, debe crear s, que tomará un modelo para validar en su constructor como parámetro, implementar la Validationinterfaz y usar estos Validators para validar sus objetos.

interface Validation
{
    public function validate();
}

class MySQLConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model here
    }
}

class RedisConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model with different set of rules here
    }
}

Si en algún momento en el futuro decide que desea agregar otro método de validación para otra capa de persistencia (porque decidió que Redis y MySQL ya no son el camino a seguir), simplemente creará otro Validatory usará su IoCcontenedor para obtener la instancia correcta basada en tu config.

Para muchos desarrolladores, el método preferido son los modelos Fat contra Stupid Ugly Controllers .

El concepto base en el texto es

... Entonces recuerde siempre que el Modelo no es solo la base de datos. ¡Incluso los datos que obtiene de los servicios web se pueden expresar como un Modelo! Sí, ¡incluso Atom se alimenta! Los marcos que recitan las introducciones al Modelo, casi nunca explican este avance que solo exacerba los malentendidos.

y

La Vista solo debe preocuparse por generar y presentar una IU para que los usuarios puedan comunicar su intención al Modelo . Los controladores son los orquestadores que traducen las entradas de la interfaz de usuario en acciones en el Modelo y transmiten la salida de cualquier Vista que haya tenido conocimiento de los Modelos que presenta. Los controladores deben definir el comportamiento de la aplicación solo en el sentido de que asignan la entrada del usuario a las llamadas en los Modelos, pero más allá de ese rol, debe quedar claro que toda la lógica de la otra aplicación está contenida en el Modelo. Los controladores son criaturas humildes con un código mínimo que simplemente preparan el escenario y dejan que las cosas funcionen de manera organizada.

La Vista solo debe preocuparse por generar y presentar una IU para que los usuarios puedan comunicar la intención al Modelo, es la parte importante. Un modelo debe definir los datos almacenados, por lo que también debe ser responsable de verificar la validez de los datos.

Al tomar el registro de una persona, cada persona debe tener un número de identificación único dado por el país. Esta comprobación (generalmente) se realiza mediante la UNIQUEcomprobación de claves por parte de la base de datos. Cada número de ID dado debe satisfacer algunos pasos de control (la suma de dígitos impares debe ser igual a la suma de dígitos pares, etc.). Este tipo de controles debe ser realizado por elModel

El controlador está recolectando datos Modely los pasa View, o reversa, recolecta los datos del usuario Viewy los pasa Model. El usuario no debe hacer ninguna restricción para acceder a los datos y validarlos Controller. Fue Controllerquien recopiló los datos de las cookies y fue el Modelque verifica si es una sesión válida o si el usuario tiene acceso a esta parte de la aplicación.

Viewes la interfaz de usuario que recopila datos del usuario o presenta datos al usuario. Las comprobaciones simples se pueden realizar por la dirección de correo electrónico deView entrada del usuario o no (por lo tanto, esto también se puede hacer en la Vista) IMO.

La vista es del lado del cliente, y no debe empujar la entrada del usuario. Javascripts puede fallar al ejecutarse en el lado del cliente, un usuario puede usar scripts escritos a mano para alterarlos o deshabilitar el script usando el navegador. Puede configurar scripts de validación del lado del cliente, pero nunca debe empujarlos y hacer una verificación real en la Modelcapa.

Las vistas deben realizar validaciones para propósitos de ff:

1. ) Una validación frontal puede reducir el tráfico de datos en su servidor.
2. ) maneja datos no válidos antes de que pueda viajar en su servidor.
3. ) si desea una mayor seguridad, una combinación de validación front-end y back-end es mejor.