For the last few days I’ve been adding validators to my DAL for the project I’ve been working on. This project is again using the LLBL Gen Pro generated datalayer.

So the validators are actually really easy to build.  I want my business rules separated from the DAL, so I create a validator by inheriting from the LLBL ValidatorBase class, override the ValidateFieldValue method, check if the new value for the field is going to be “” and return false if it is, and then attach an instance of the validator to the entity when the entity is created.  Presto, like magic the method fires when I try to assign a blank string to the field, the error message for that field gets set, and the SetNewValue method returns false saying it didn’t set the value.

Here’s where things start to fall apart…

The first thing I found is that SetNewValue returns false whenever it didn’t set the value of the field, not when it got an error.  This could mean that the validation failed, but it also returns false when you are going to set the value of the field to the same value that is already there.  So false may mean there is a problem, or it may mean that the data simply hasn’t changed.  Well, I guess that makes that flag kinda useless for checking for errors.

But wait.  If I break any of the basic rules that the entity enforces on its base type (data type, data length, not null, etc), it doesn’t return false, it throws an Exception instead.  Now maybe I’m just weird, but I expect my validation routines to simply check the data and then return IsValid (true/false).  Then I will do whatever I want to do about invalid data.  To me this is a bad use of an exception.  It interrupts the flow of the code not because something catastrophic or unexpected has occurred, but simply because the user entered bad data.  That’s hardly an unexpected event.  Worse, if you are scraping many new values off of the form and updating the entity, the exception is going to cause it to stop as soon as the first validation error occurs, so you don’t get any feedback on the rest of the fields.  Ick.  Click Submit, get error, fix error, click submit, get next error…  To stop this you would either have to do the updates in a loop so you can catch each error as they happen (which thankfully I am), or else build code that looks something like this…

Try {
   retval = SetNewFieldValue (Company.Name, “McDonalds”)
}
catch(ORMEntityValidationException ex) {
   //Handle error
}
Try {
   retval = SetNewFieldValue (Company.ID, 1)
}
catch(ORMEntityValidationException ex) {
   //Handle error
}

Now that’s just plain ugly. Each line it it’s own try/catch?

The author of LLBL does make one comment that caused me to put the same exceptions in my own validator though (since I had to handle the exceptions anyway).

“The exception makes sure any transaction currently in progress will be terminated.”

Ok, that is a good thing. I still think an exception is the wrong way to handle it though.