For and Asp.Net MVC 4 Web Application + API + Windows Service, what is the right place to put the validation - On Model or ViewModel?

Question

I am relatively new to MVC and trying to put together a framework for a MVC 4 based web application.

This question is somewhat similar is nature to mine, but I have a particular situation that I want the community to evaluate and provide me inputs on.

I have a software system that has two components - an MVC 4 web application and a windows service. The "model" layer (I am referring to the domain tables etc.) will be accessed by both the Windows Service and the Web Application.

I also have plans to expose a good amount of functionality to mobile apps in the near future and the API will also consume the model.

The overlap in functionality will be in case of the web application and the API (mobile apps)

Here are some questions specific to my case:

1. Is it a good idea to reuse View Models across the Web application and the API for the same functionality (e.g. update address of an individual exposed on the web and the mobile app)? Where should the validation (e.g. address validation - like address line, city, state, zip all combined) reside?
2. The Windows Service functionality is more complimentary in nature to the web+API (e.g. a nightly job that sends out reminder emails), but will likely overlap with the "Model" part used by the Web+API. Is it a good idea that the service use the "Model" directly or have a layer like the "ViewModel". Where would validation go in this case?
3. Another conceptual question that I would like more information on is - The attribute driven validation is implemented by virtue of the MVC framework, i.e. it is the MVC architecture that takes the view model, finds the validation attribute on the view model properties and injects relevant validation. How would this attribute driven validation work in case of an API and when the model is consumed by a windows service?

Answer 1

Best place to put validation (model or viewmodel)?

is a proxy question for Best approach to error validation. And that can start a religious debate. And interestingly have you, assumed another location isnt an option?

A List of PROs and CONs or points to consider is a good place to Start. But the right choice depends on the size and complexity of the task at hand. eg I want to be able reuse all error validation from any Channel (webUI/Windows UI/ WCF API etc) I want to declare "rules" centrally and have them appear everywhere and translated. I want to avoid Database constraints as error checking approach. But Data Access layer Validation is also part of the approach and how it is handled with exceptions. EG concurrency. So as you can see there is no simple answer.

Considerations:

Model Validation

• annotations, eg [Required],[StringLength(n)]
• use IValidatableObject
• both can be checked or triggered by other frameworks eg MVC, Entity Framework
• checks that refer to an object directly and suit DDD. An object should know its base business rules eg If field X, then Y must.....
• BUT Cant easily do cross object checks, eg checking for logical duplicates.
• Layer separation and inversion of control challenges if you need to "read" other data to do a check.
• Cross object checks dont fit on a model well and really require their own layer/level

View Model Check

• How to inherit Annotations from Interfaces. So how to avoid duplication of "Rules" in annotations in view model.

• Approach to client side versus server side validation will drive some design. Choice of Client side validation technique is also import. MVC annotations, Data- , custom javascript frameworks ?

• Some rules in VIew Models apply to the process and not an individual Object. Should this logic be in a ViewModel ? or Business Process Layer ?

Personally i think a core OUT approach is best. Declare as many rules as possible in Model directly. But Also have Business Process layer Rules. Use a Business Process/ Service Layer to do Business level, cross object checks. Inherit , or bring central rules out without duplication if possible. More effort in build is required to go beyond simple annotations. eg [required] in view model is easily done. Maintaining it not hard, but messy depending on how many models and view model combinations. But Using Json/Ajax with custom built Rules that are dragged from a central point is the another option involving complex javascript and some "meta" data approach in your model.

And of course Use client side validation for usability.

Answer 2

Disclamer: I'm not sure what the right answer is, but I'll comment anyways (no expectation to accept). Also, this answer doesn't address 1,2 or 3.

On my current project we use validation in the view model and on the database side. The validation on the view models can provide some feedback to the user as the validation on the view model can be used with the unobtrusive ajax to provide that feedback when they post an invalid view model.

The validation prior to the database is for checking the correctness of the data and largely duplicates the validations and custom validations in the viewmodel. Sometimes, the databse validation has additional checks, and then if there is an invalid model, the errors are shuttled back to the view. Its quite inefficient, and I hope somebody proposes a better solution.

ADDITIONAL INFO: heres another helpfull hint. its possible to use viewmodel validation on objects from the api or windows service provided they have the same properties, see How can I use the Data Validation Attributes in C# in a non-ASP.net context?