views:

536

answers:

2

I'm wondering if any best practices exist for guidelines as to what should and should not go into a validator control. My thought and practice was that it should be basic sanity checking (i.e. did the user enter all the required inputs? Is there 10 digits in the phone number, is the email address in the valid form? etc..), but I've recently run across a fair bit of asp.net code that is using validators for much more complex validation (i.e. web service calls to verify addresses or that the user id and name match).

Are there any schools of thought out there regarding how these more complex tasks should be encapsulated? My initial instinct is that validators are the wrong tool for the job, but I'd really like to know what other people think or have written about it. Thanks!

A: 

You're right. The p&p team has a great block in Enterprise Library, named Validation Application Block (VAB).

Validation within the UI is fine if you are collecting values directly from users, but you may need to do more. For example, you may need to validate object instances that you:

  • Generate in separate tiers or components of your application
  • Retrieve from a cache, a repository, or a third-party data access layer
  • Receive from a Web Service as an object instance or a set of property values
  • Reconstruct from existing values, perhaps populating them by copying properties from a similar object or using values retrieved from a database

I'm a big fan of Enterprise Library and have good experiences with VAB. If you're not familiar with EntLib it's can be hard first time - but it rocks after that!

VAB gives you the option to create, run and host your rules in one place, but call there where you need it.

15 seconds with ASP.NET and VAB:

http://www.15seconds.com/Issue/070607.htm

Tom Hollander's blog about VAB

http://blogs.msdn.com/tomholl/archive/2006/11/27/validation-application-block-revealed.aspx

boj
It's not that I'm trying to validate something other then user input, but rather that the validation of the user input is complex and potentially expensive. After looking at your links and doing a bit of googling, I don't think that VAB is the right tool either.
Nathaniel Reinhart
Aha...you may should read/try ASP.MVC. ASP.NET it's a nice but a little mixed and dirty framework. With separation of concerns (model, view, controller) and MVC based validation tools (ie. xVal) maybe you'll find a better answer.
boj
I would definitely rather be using ASP.MVC, but unfortunately this is legacy code that isn't going anywhere today.
Nathaniel Reinhart
Aha...maybe refactoring out all validators into classes (using the strategy pattern or chaining the rules with the chain of responsibility pattern?)
boj
A: 

I don't know if it is a best practice or not, but my personal opinion is that the only thing that should be validated on the client side are things that can be completely validated on the client side. In other words, if you have to make a call to a server in order to perform the validation, you have already lost any performance gains from validating on the client. (And that is why the validation is on the client - to gain performance by avoiding a trip to the server.)

Since your business object is (or should be) performing the same validations on a submit, it makes more sense from a coding and maintenance point of view to allow the form submit and perform all the validations at that point.

Jason Berkan