¿La validación de ASP.Net MVC 2 necesita más reflexión en términos de patrones y uso?

Question

Aquí está la disposición de la tierra. Como la mayoría de las personas, tengo mi objeto de dominio y tengo mis modelos de vista. Me encanta la idea de usar modelos de vista, ya que permite que los modelos se creen específicamente para un contexto de vista dado, sin necesidad de alterar mis objetos comerciales.

El problema que tengo es con la validación de nivel de tipo definida en mi objeto de dominio y obteniendo esas reglas para el cliente. En este caso digamos que estoy usando anotaciones de datos para describir las reglas de validación, cuando muevo los datos del objeto de dominio al modelo de vista, el modelo de vista ya no sabe qué validación debe realizar la interfaz (porque la validación es definido de nuevo en el objeto de dominio).

Con MVC 2 puede obtenerlo para realizar automáticamente la validación del lado del cliente/servidor, de acuerdo con las reglas de validación del objeto actual. Pero debido a que las reglas de validación están definidas en el objeto de dominio y no en el modelo de vista, tendría que duplicar las reglas de validación en el modelo de vista para que funcione.

¿Cómo lidian otros con este tipo de problema? Mi pensamiento es que además de mapear los datos del objeto de dominio al modelo de vista, también tenemos que mapear las reglas de validación, pero realmente no he visto a otros hablar sobre este tema ... Brad Wilson ha hablado recientemente sobre este tema pero no ha abordado realmente la duplicación de reglas en el objeto de dominio y en los modelos de vista ... ¿cuáles son sus pensamientos?

Saludos Anthony

Answer 1

Los atributos de la anotación de datos se refieren a la validación de la entrada y a la realimentación de la UI al usuario final. Ese es realmente su único uso previsto. Utilizo diferentes estrategias de validación para objetos UI y objetos comerciales, por lo que los atributos de validación DA solo terminan en modelos que se muestran al usuario.

Answer 2

Esto puede no ser adecuado, pero lo que si se acaba de mudar las reglas de validación/anotaciones de sus modelos a sus ViewModels? En algunos de los proyectos en los que he estado, hemos decidido evitar que la Vista acceda a todo menos a la información expuesta a través de su ViewModel correspondiente. Dado que toda la interacción de datos se realizaría a través del ViewModel, no habría necesidad de tener validación en sus objetos Model.

El contador de este argumento es que podría duplicar fácilmente ciertas reglas de validación, ya que diferentes modelos de vista podrían interactuar con los mismos modelos. En este caso, podría tener sentido simplemente declarar su Modelo como una propiedad expuesta en su ViewModel. Para las devoluciones, podrían aceptar un modelo como su parámetro, permitiendo que la infraestructura de ModelBinder maneje la solicitud. En este caso, si ModelState.IsValid es falso, puede reasignar la propiedad a su ViewModel antes de volver a mostrar la Vista.

Recomendaría mover sus anotaciones a su ViewModels. Tiene sentido ya que muchas Vistas son a) el resultado de la composición de varios modelos ob) un subconjunto de datos del modelo.

Answer 3

¿Probablemente no deberíamos usar modelos de vista en absoluto? Y defina las reglas de validación en las entidades de la capa del modelo.

Answer 4

He estado considerando esto también desde hace un tiempo. Entiendo totalmente la respuesta de Brad. Sin embargo, supongamos que quiero utilizar otro marco de validación que sea adecuado para anotar ambas entidades de dominio y ver modelos.

La única solución que puedo encontrar en un documento que todavía funciona con atributos sería crear otro atributo que "apunte" a la propiedad de una entidad de dominio que está duplicando en su modelo de vista.He aquí un ejemplo:

// In UI as a view model. 
public class UserRegistration { 
    [ValidationDependency<Person>(x => x.FirstName)] 
    public string FirstName { get; set; } 

    [ValidationDependency<Person>(x => x.LastName)] 
    public string LastName { get; set; } 

    [ValidationDependency<Membership>(x => x.Username)] 
    public string Username { get; set; } 

    [ValidationDependency<Membership>(x => x.Password)] 
    public string Password { get; set; } 
} 

un marco como XVal posiblemente podría extenderse a manejar este nuevo atributo y ejecutar los atributos de validación en la propiedad clase de dependencia, pero con el valor de la propiedad de su modelo de vista. Simplemente no he tenido tiempo de explicar esto más.

¿Alguna idea?

Answer 5

Resulta que AutoMapper puede hacer esto para nosotros automágicamente, que es el mejor de los casos.

Usuarios de AutoMapper: ¿Transfieren atributos de validación al viewmodel?
http://groups.google.com/group/automapper-users/browse_thread/thread/efa1d551e498311c/db4e7f6c93a77302?lnk=gst&q=validation#db4e7f6c93a77302

No he tenido tiempo de probar las soluciones propuestas allí, pero tengo la intención de hacerlo en breve.

(Cross publicó esto en mi (engaño) pregunta también).