MVC, ViewModels and Validation

Question

I am creating an MVC3 application with EF4 using POCOs. I have added validation attributes for my EF objects. Now, when I create the views, I want to use the view model (and maybe use AutoMapper to populate them).

The problem I am facing is that I have to override my validation attributes on my view model, which violates the DRY principle. For example, if I decide to resize the field, I need to change the MaxLength attribute on both POCO and any view models that use it.

Is there any tricky way to map validation rules from my POCOs to my view model?

Answer 1

I also struggle with this, and I agree that he violates DRY. I posted a recent question about this here and got quite a bit of feedback.

You can never be the perfect DRY in any real application. Sometimes you get more benefit from violating a principle than trying to stick to it blindly.

EDIT:

You might also think that DRY might violate the principle of single responsibility (SRP). By reusing the same code, you are now invoking the code to do more than one. If you think that data models and view models have different goals, and therefore different responsibilities ... bringing them into a single model violates SRP. That is, making your data model also a view model is two different responsibilities.

Now you can think of several ways to potentially reconcile SRP with DRY in this regard, but at some point you need to weigh the cost benefits.

Answer 2

Personally, I am checking on view models. This is what the controller receives from the view, and it is a class that contains user input. I distinguish between two types of validation rules: surface validation and business validation. Rules, such as required fields, correct formats, should be applied on presentation models, while business rules, such as a user with a given name, already existing in the database, should be checked on the model.

In addition, you may have different view models that are mapped to the same model, but based on the rules of the view, they may differ. Because of this, you will not have exactly the same validation rules on view models.

Answer 3

One approach that gets some abstraction is to have a ViewModel made up of your business model class, including other relevant viewing information.

class MyObject { public int ID {get;set} [Required] [StringLength(512)] public string Name {get;set;} } class MyViewModel // ViewModel for a specific view { public MyObject MyModel {get;set;} // the model that is being edited // other data the view might need, set by the controller public string SomeMessage { get; set; } public List<SomeObject> SomeObjects {get;set;} /// eg for a drop-down list } 

Then in the ViewModel link respectively.

 @model My.Namespace.MyViewModel Hello @model.MyModel.Name !!! 

Thus, you will indicate only your confirmations and / or data annotations in your business class in one place.

If you want to have a different validation, this will require some strategy to selectively apply validation logic.