.NET Validation Framework Analysis (draft)

1

December 3, 2009 by temebele

Purpose: to improve our data validation and provide a better user experience

Goal: being able to define our validation rules once on our domain model and use the same rules both on the server and client. Below is a diagram taken from xVal’s web site that clearly shows what we are trying to achieve. (http://blog.codeville.net/wp-content/uploads/2009/01/image-thumb.png)



After looking at different validation frameworks* I’ve tried to come up with a short list of the ones that I thought are widely adopted and worth considering for our scenario.

Server Side Validation

Implementation: Metadata attributes applied to domain model classes

    • Pros
      • Developed and supported by Microsoft
      • MVC 2 Default model binders supports it out of the box
      • They have provided a way to customize metadata for existing entities through  “buddy classes”

    • Cons
      • It is not tightly integrated with NHibernate
        • Does not generate SQL constraints based on attributes
        • It can be customized but doesn’t have built in support to intercept NHibernate PreInsert and PreUpdate events
        • Overhead with using reflection
    • Pros
      • Tight integration with NHibernate
        • By default it can intercept the PreInsert and PreSave NHibernate entity  events and provide validation before persistence
      • Schema generation
        • It can generate SQL constraints based on the validation rules
    • Cons
      • Requires implementing custom Model Binder to integrate with MVC applications
      • There is no built in support for translating the NHibernate validator rules to client side rules (xVal has NHibernateValidator runner but it didn’t catch up with the many revisions of NHibernateValidator. MVC 2 also promises that we can use it with any validation framework but it is not out of the box feature.)
      • Overhead with using reflection

MVC Client Side Validation

1. MVC 2 Validation Support
http://bradwilson.typepad.com/blog/2009/04/dataannotations-and-aspnet-mvc.html

a. Pros

i. The default model binder supports validation that use .NET 3.5 Data Annotation

ii. It also supports generating the JSON validation meta data for models annotated using .NET 3.5 Data annotations

iii. It can be customized to work with any server side validation library

b. Cons

i. Requires upgrading to ASP.NET MVC 2 Beta

2. xVal – Open source tool to link our choice of server side validation library to client side validation library
http://xval.codeplex.com/

a. Pros

i. Widely adopted

ii. Default support for .NET 3.5 Data Annotation

iii. It can be customized to use with other validation frameworks

iv. It doesn’t require upgrading to MVC 2 Beta

v. Remote Ajax validation support

b. Cons

i. It uses exceptions for communicating validation rule violations and thus more geared towards creating a separate Validation Service Layer

ii. It creates dependency on another open source tool where MS is already providing the equivalent

Recommendation:

I recommend using .NET 3.5 Data annotation and upgrading ASP.NET MVC library to ASP.NET MVC 2 Beta for the following reasons:

· Most of our SQL script are created manually and not through the schema export feature of NHibernate and thus won’t benefit from SQL constraints auto generation feature that comes with using NHiberante validator

· Both MVC and Data Annotation coming from Microsoft thus there is a good potential that we can benefit from future development efforts in both areas that go in parallel. Also it would easier to integrate with WCF, Dynamic Data, WPF and other MS products.

(This was comparing it to the non-parallel development that we see with Opens source tools. E.g. xVal’s NHibernateValidationRunner and NHibernateValidator)

· Ease of implementation because of the out of the box support of MVC 2 for .NET 3.5 Data annotation

Field Level Validation – Using metadata attributes applied on Entity properties

Entity Level Validation – Using custom metadata attribute applied on a class level

Business Rule Validation – Custom metadata attributes applied on a class level should be able to satisfy most of our business rule validations. For some scenarios where we have application specific validation where entity level validation is not enough, we might need to create a thin validation service layer on top of the MVC controllers.


Note: Even though you decide to use one of the validation frameworks, our Design should be flexible enough to support switching to another validation framework if the need arises in the future.  (We can adapt the validation architectures used in S#ARP Architecture http://wiki.sharparchitecture.net/default.aspx?AspxAutoDetectCookieSupport=1)

Other Questions?

Should the data annotation attributes be applied only on the domain model or can it sometimes be applied on the view model?

*  some of the frameworks Ilooked at include Validation Application Block, NHibernate Validator, MS Data Annotation,Fluent.NET Validation and using delegates with  IDataErrorInfo

Advertisements

One thought on “.NET Validation Framework Analysis (draft)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: