Validation logic should live in one place....your business layer!

Rhocky has an interesting post which poses the question...Should validation logic be in the UI or in business objects?

To get right to the point, validation logic should be in your business object layer.  End of story.

Ok, it's not really the end of story I have more to say on the subject.  As Rhocky points out in his post most (if not all) asp.net applications have all validation logic in the UI only.  For some trivial applications that might be enough but for most applications that doesn't cut it. 

Rather then focusing your attention on getting all the validation logic setup in your GUI you should instead be focusing on how you can define the validation rules in one place and have it applied in several different scenarios.  By putting validation rules in one place you can then use those rules to perform validation in your UI, as well as within your business layer.  This helps you ensure that you don't end up with any invalid data in your system. [1]  The rules can be applied before your data layer saves your objects to their persistance store and the rules can be retrieved by the UI and used to dynamically build the UI validation necessary.

So I'm guessing at this point I have a lot of people thinking that theoretically I'm on the mark but actually going and implementing something like this is another story.  Since the specifics of how something like this could be done is a little beyond the scope of this post I'm going to leave you with this.  It can be done, and once the groundwork is laid you will be very pleased that you spent some extra time getting it setup.  It's extremely nice to be able to define your business rules in one spot and have them applied when your objects are saved as well as when UI screens are rendered to the user.  I've implemented such a framework in the web world while building ActiveType as well as in the Windows world.  To be fair I've just started developing something for WinForms, but I'm confident it's going to work

To conclude...rather the placing validation rules directly in your UI or duplicating them in both your UI and business layer think about how you might be able to define them in one place and have them applied in multiple scenarios.  I'll dive into some of the details of how I've done this in the web and WinForms world in future posts.  Maybe I'll even include some code *gasp*.

[1] This of course assumes your not letting people access the backend database directly in which case the rules that aren't enforced in your database won't be applied.

# re: Validation logic should live in one place....your business layer!

Saturday, March 04, 2006 8:02 PM by Bil Simser    
I agree that business entities should be doing validation but I've had this argument with others.

Take for example a salary range if you're defining an employee in a system. In your web app, do you really want to go all the way back to the business layer to perform a validation on this? People have argued with me that since it's a validation (vs calculation) why not do it in the UI so it can be done quickly without a postback. Imagine a web form with a dozen fields that all have to be validated. Also there's an issue when you have mulitiple validations. Again, multiple trips back to the business layer to do this doesn't seem right.

I'm in total agreement that validation should be in the business entities because you don't always have a UI and writing unit tests should be against the business objects, however is it really reasonable to say that they'll be no validation in the UI (or the database for that matter) and how do you split up validation (or duplicate it) across the layers.

A perfect system would probably have all the validation in the business layer and you can only access the database through creating business objects, but this isn't always realistic with applications.

Would be interested what your thoughts on that are, as I always get shot down by people when I want to solely validate in the business layer.

# re: Validation logic should live in one place....your business layer!

Saturday, March 04, 2006 10:05 PM by Steve    
Bill, Thanks for the thoughts.

Although I believe 100% in having the validation rules defined in the business layer that isn't to say that I don't think any validation should happen in the UI. I just don't want the same rules defined in two places. Rather then defining the validation rules in the UI as well as the business layer, why not define them in the one place they belong, the business layer, and then make it possible to have those rules applied in other layers...such as the UI.

Look for some posts in the near term with some more concrete examples of how this can be done.

Cheers,
Steve

# re: Validation logic should live in one place....your business layer!

Monday, March 06, 2006 9:26 PM by Darrell    
I'd also add that Rocky says that web apps have all the validation in the UI because he's a smart client guy and it's always fun to trash talk the other side. :) I can tell you that it's not true for a *well-written* app.

# re: Validation logic should live in one place....your business layer!

Monday, March 06, 2006 9:46 PM by Steve    
Very good point. Those pain in the ass "smart client guys" are always talking trash on the other side. The one thing that Rocky does have on his side is that most apps aren't well-written :)

# re: Validation logic should live in one place....your business layer!

Saturday, January 20, 2007 12:32 AM by John Rusk    
I'm also working on something in this space, with the intention that rules will run both client-side and server-side.

I've recently put the first release up on my site.

Post a Comment

 
 
Prove you're not a spammer: 
6 + 6 =