.Net, ASP.Net, MVC

Handling Validation Errors in MVC (a different approach)

I just got done reading Scott Guthrie‘s and Phil Haack’s posts on the MVC Preview 4 release and there was one little piece in the “What’s Next” section that really peeked my interest. As it turns out the MVC guys are figuring out how to tackle the problem with handling validation errors and reporting them back to the user. How great is that? I don’t know about you but validation errors are one of the worst things to have to deal with when it comes to a web based application.

As we all know you should never rely on client side validation and you should always validate input (especially user input) prior to calling any business methods or database calls. My problem has always been with trying to get the validation messages back to the client. I am always determined to have my validation routines in my business layer. But then comes time to report validation errors back to the client and I end up sticking them in the code behind. Sure I might (emphasis on might) create a utility or helper class but then the routines become more and more specific and less and less common and I am right back to sticking them in the code behind.

Where else can you put them since you not only have access to the control but you also have all the tools you need to render the output?

While I have been playing with MVC I have found myself once again struggling with sending validation messages back to the user. This time, however, I decided to try a few different techniques and one has proven to work well (for me at least).

I first started off creating a class to store my validation messages. Since my primary focus is capturing form related validation errors I decided to add a PropertyInfo property that will give me some more context later on if I need it.


So now that I have a class that contains a validation message with some extra info layered in I turn my attention to how to store the errors. At first I decided to make a single collection that would be used as the return type of my validation routines but quickly found it to be too restrictive. I decided to leverage the HttpContext.Items collection and the CallContext class instead. The HttpContext.Items collection for web based usage and the CallContext for unit testing. To isolate myself from these details I created a little wrapper class to manage the switching between web usage and unit testing.


This class uses generic methods so I can strongly type the objects being stored.
With that out of the way I created another class specific to my validation storage which does nothing more than make calls to the ThreadContext class.


Finally I create a class that handles the addition and retrieval of the validation messages.
Let’s first take a look at the constructor for this class.


As you can see I first create a new collection to store the validation messages. Next I check to see if a ValidationStorage class already exists and if so I set the existing instance to the Parent property (more on this later). Finally I make the instance the Current object in the ValidationStorage class. I could have easily used a Stack of Validator but rather than popping and pushing I decided to take this approach instead.

Now let’s turn our attention to the Dispose method.


As you can see here when I dispose the Validator object I check to see if the instance has a Parent and if it does I take it’s Details and add them to Parent.Details.

Now on to the properties. Nothing much going on here but in order to understand what the methods are doing you will need to know the properties that are available.


The Current and Exists properties make calls to the ValidationStorage class. The Failed property will return “false” if a Validator does not exist in the ValidationStorage. Later on you get a better understand of why these properties are static.

On to the instance methods.


The HasMessages method allows me to check to see if I have any ValidationDetail for a given property by name. And if there are messages then I can call GetMessage or GetMessages.

Finally the static methods. These methods are what will be accessed from within the validation routines.


Thee methods add the ValidationDetail object to the Details collection. Prior to adding it, however, I check to see if there is an existing Validator available to use and if not I new up a new instance. The Error and Exception methods will also pass in a boolean to the AddDetail method to indicate that validation has failed.

So now let’s take a look at how to use this. For simplicity assume that there is a controller that performs some basic validation routines against a simple model. Let’s first take a look at the model.


The controller then needs to have a few validation routines so let’s look at those now.


As you can see here when a validation error occurs I simply call the static method Error and that’s it. But how does it convey the messages back to the client? This can bee seen in the following code.


After the controller calls the validation routines it makes a call to the static Failed property of the Validator class which will indicate whether or not validation has failed (obviously). If it has failed validation then I simply render the Edit view again. Within the Edit view a check is made to see if a Validator exists using the Exists property and if so the the ValidatioDetail objects can be blindly displayed or a check against per property can be made for a more contextual error messages.


One key thing that I think really makes this work well is the ability that this gives to call the Validator from almost anywhere in my code. Validation routines can now reside within the business layer like they should. And since the ThreadContext is in place web services can use and implement the same checks that are done in the controller.

While I think this does the job I also feel that there can be some things improved upon or added to really make it shine. For instance:

  • Adding a severity property which would indicate if the client has entered something really harmful and allow for an exception page to be rendered
  • Changing the Details collection to a Dictionary to easily store multiple validation errors per property or data element
  • Add an Html extension method to deal with the checking and displaying of validation messages

Any ideas or comments are welcomed.

kick it on DotNetKicks.com


New ASP.Net MVC Source Drop

Scott Guthrie recently posted about the new ASP.Net MVC Source Preview and I have to tell you that I am really excited about these new bits. Not only have they added the source code for the unit tests with this release but that have added two new features that I think are really going to make life easier.

If you have played around with ASP.Net MVC, or have read articles covering it, you will know that one of the key features to ASP.Net MVC is the support for unit testing in the Presentation tier. Prior to ASP.Net MVC you could perform some unit testing in the Presentation tier but often times you were required to use a record/playback mechanism that did nothing more than record the HTTP request, store the data in some XML or other file format, and allowed you to "replay" the scenario. More times than not, however, the amount of time and effort to test this tier was too much to make it a common everyday task that developers would follow.

In the first few releases of the MVC framework the ability to create and execute unit tests has been made a lot easier and a ton more manageable. The biggest complaints out there were that you had to using a "mocking" framework or stub out the entire HttpContext to test the Controllers. And while Preview 2 of the MVC framework has even made this easier with the IViewEngine and the HttpContextBase class.

Well… now comes the latest bits. Now in the latest drop you don’t need to mock anything or create a fake ViewEngine. This is all thanks the to the ActionResult class which is returned for every method call in a Controller class. Not only does this new class make it even easier to unit test your Presentation tier but it also opens up a bunch of other opportunities since the ActionResult class contains the ViewData object as well.

But wait… it get’s better (boy… do I sound like a late night commercial or what)

This release also contains some changes that have been made to the URL Route Mapping feature. In these bits you can now include characters like "-" and "." in your route. The most impressive example that was given in Scott’s article was the file extension or format example. In this example Scott shows how you can produce a route which would provide an extension to determine the what format to use when rendering the data.

For example, the route "products/browse/{category}.{format}" would pass the "category" and the "format" to the Controller. Now imagine that we use a URI like "products/browse/cars.xml". This would not only tell the Controller to go and get the data for the "cars" category but it would also let us know that the user is expecting this in an XML format. Now consider a URI like "products/browse/cars.json" or "products/browse/cars.yaml". The Controller would be able to determine the right View to execute based on format. Or perhaps we would be able to advantage of the ActionResult and create a Factory which based on the format returns a sub-class of ActionResult which we can filter on.

I can only imagine what they are coming up with for the next drop… if it is anything like this… it’s going to be good.


ASP.Net MVC Source Code Available… our first test

Scott Guthrie recently posted an article about the ASP.Net MVC Source Code becoming available from the CodePlex website.

I think that this a huge step in the right direction. I would even go as far as saying that this “move” was intentional. If you take a minute and think about what this means… you will see what I am talking about.

With the source code to the MVC library being made available… it is almost like we as developers are being tested. Will we take the source code and make it our own? Will we report back defects and enhancements back to Microsoft to improve this feature? Will we open it up and try to break it and find flaws in the underlying code?

My point being that if we take the right approach as a community and as a team then not only will we (the end users of these features) become more familiar and confident with these bits but our input and feedback will find a larger and more important audience in the long run.

Is that to say that when I (a simple developer in the .Net world) find an issue with the way that they (the developers at Microsoft) implemented some piece of code expect it to be corrected? No. Is that to say that when I feel like there is a feature or method that can make my life easier it will be included in the final release? No.

What it does mean is that I am given a chance to make the community, feature, and the platform as a whole better. Sure… I am only one voice. If my voice is included along with others… it becomes easier to hear. If I am given the chance to work with and validate the feature as a “real world developer” then when the feature or functionality is incorporated… we are the ones to blame if something doesn’t do what the rest of developers feel like it should.

All and all… I feel like this is a tremendous opportunity that is being given. While this would not be considered “open source” by any stretch of the imagination, I (little old me… a simple developer) am being given the chance… to change… Microsoft and the .Net language.

Take a minute and think about what that means to you…
Do you want to be a part of the community or simply consume it?

kick it on DotNetKicks.com