In my previous article about ASP.NET MVC Client-Side validation, I showed how to set up your project so that you don’t have to write any custom JavaScript code for any new validation rules. This approach also covered remote client-side validation – these are rules which require server-side resource in order if a particular input field is valid or not.

Since I wrote the first part of the article, Steve Sanderson adopted my idea of automatic client-side validation and baked a similar feature right into the latest version of xVal.

One important thing is still missing though: What do you do when validation depends on server-side resources but also involves several different form fields? For example, let’s assume you were implementing a form for your website users to update their contact information.

(more…)

Client-side form validation has become a de-facto standard for modern web applications. However, replicating server-side validation rules on the client side can be a tedious and error-prone process.

In addition, there are some validation rules which cannot be checked completely on the client side, for example because the validation depends on information stored in the server database. For those rules you need to implement remote client-side form validation.

The xVal framework is great for automatic generation of client-side validation code for some of your server-side validation rules, but it does not support remote client-side validation.

This article shows a fully generic way to implement remote client-side form validation so that

• Validation rules remain solely in your ASP.NET MVC model
• You write each validation rule just once, and only in easily testable C# code. There is no JavaScript or other client-side counterpart .
• There is no need to branch or otherwise modify xVal or jquery.validate
• All you have to do for each new remote form validation rule is to derive from the base class shown in this article.

I’ll describe how to implement this in detail. I’ve also uploaded a demo project showing how this works in action.

(more…)

I like the compiler to catch as many errors as possible before I start debugging or release my application. This also applies to code nuggets in ASP.NET MVC views, especially since these are not easily unit-testable. But views are not validated at compilation, at least not when using the standard settings for ASP.NET MVC projects.

Tools like Resharper can notify you of syntax errors within your views, but you can still build the project and not get a single error. Instead, your application will crash when trying to evaluate the buggy view.

Fortunately you can easily make Visual Studio compile your views along with the rest of your code. (more…)

One of the top good practices for ASP.NET MVC is not to use the ViewData Dictionary, but to put your data in a strongly typed ViewModel instead. Many people seem to be using Linq to SQL entities as a ViewModel, because it’s a very comfortable approach. But what do you do if your view should contain data that is not included in any of your linq entities? Scott Gu’s chapter 1 preview of his upcoming ASP.NET MVC book recommends using a custom-shaped ViewModel for those cases. (more…)