validaciones en MVC/MVP

Question

Soy nuevo en MVC/MVP y lo aprendemos creando una aplicación Winform.

He creado hasta cierto punto los Modelos, Presentadores y Vistas ... Ahora, ¿dónde encajan mis validaciones?

Creo que la validación de tipo de datos inicial (como solo los números en el campo Edad), debe hacerse por vista. Mientras que las otras validaciones (como si la edad está dentro de 200) debe hacerse por modelo.

En cuanto a la validación de tipo de datos, mi punto de vista expone los valores como propiedades

public int? Age 
{ 
    get 
    { 
     int val; 
     if (Int32.TryParse(TbxAge.Text, out val)) 
     { 
      return val; 
     } 
     return null; 
    } 
    set 
    { 
     TbxAge.Text = value; 
    } 
} 

puedo realizar la validación por separado, pero no como me informo presentador que la validación aún está pendiente, cuando se trata de acceder a la Edad de la propiedad?. Particularmente cuando el campo es opcional.

Es bueno emitir una excepción de validación, pero luego el presentador debe atraparla en cada punto.

Entiendo correctamente, o me falta algo.

Actualización (en aras de la claridad): En este caso simple donde el campo de edad es opcional, ¿qué debo hacer cuando el usuario escribe su nombre en lugar de un número. No puedo pasar el nulo ya que eso significa que el campo ha quedado vacío por el usuario. Entonces, ¿cómo informo al presentador que se han ingresado datos no válidos ...

Answer 1

Viniendo desde el lado de MVP (creo que es más apropiado para WinForms) la respuesta a su pregunta es discutible. Sin embargo, la clave para mi comprensión fue que en cualquier momento debería poder cambiar su punto de vista. Es decir, debería poder proporcionar una nueva vista de WinForms para mostrar su aplicación o conectarla a una interfaz ASP.NET MVC.

Una vez que te das cuenta de esto, la validación se convierte en aparant. La aplicación en sí (la lógica de negocios) debe arrojar excepciones, manejar errores, etc. La lógica de la interfaz de usuario debería ser tonta. En otras palabras, para una vista de WinForms debe asegurarse de que el campo no esté vacío, etc. Muchas de las propiedades de los controles permiten esto: el panel de propiedades de Visual Studio. La validación de codificación en la GUI para los gustos de throwing exceptions es un gran no, no. Si tuviera que validar tanto la vista como el modelo, estaría duplicando el código; todo lo que necesita es una validación simple como, por ejemplo, que los controles no estén vacíos. Deje que la aplicación real realice la validación real.

Imagine si cambié su vista a una interfaz de usuario ASP.NET MVC. No habría dicho controles, y por lo tanto se requeriría alguna forma de scripting del lado del cliente. El punto que estoy planteando es que el único código que debe escribir es para las vistas, es decir, no intente generalizar la validación de la interfaz de usuario en las vistas, ya que frustrará el propósito de separar sus inquietudes.

Su aplicación principal debe tener toda su lógica dentro de ella.La lógica de vista especificada (propiedades de WinForms, Javascript, etc.) debe ser única por vista. Tener propiedades e interfaces que cada vista debe validar es erróneo en mi opinión.

Answer 2

Creo que la validación de vistas solo es relevante en javascript ya que la vista no ejecuta ningún código en la publicación, solo el controlador lo hace.

Pero tampoco confío nunca en la validación de JavaScript ya que un usuario malintencionado podría omitirla o un usuario ignorante podría tener JS deshabilitada, así que repita cualquier validación de JS en el código del servidor en el controlador.

La vista puede tener medios para mostrar cualquier error.

Answer 3

Si su "vista expone los valores como propiedades", sospecho que le falta algo. La principal distinción entre MVP/MVC y algunos de los otros patrones de desacoplamiento de la interfaz de usuario es que incluyen un modelo, que pretende ser el contenedor principal de los datos compartidos por la vista y el presentador o controlador.

Si está utilizando el modelo como contenedor de datos, la responsabilidad de la validación queda bastante clara. Como solo el presentador (o controlador) en realidad hace algo más que mostrar los datos, es el responsable de verificar que los datos estén en un estado aceptable para la operación que está a punto de realizar.

La adición de indicadores visuales de problemas de validación de datos a un formulario/ventana del editor durante la edición es realmente agradable. Sin embargo, se debe considerar más o menos equivalente para ver "ojos dulces", y se debe tratar como un complemento de la lógica de validación real (incluso si se basa en metadatos o códigos compartidos). El presentador (o controlador) debe seguir siendo la verdadera autoridad para la validez de los datos, y su código de validación no debe estar alojado en la vista.