Using ValidationRules that Query the Database

skehiaian posted on Wednesday, July 19, 2006

I wanted to get some thoughts about the pros & cons about accessing the database from within custom validation rules. Part of the requirements for my objects are that some of the fields must be unique. Therefore it would be very intuitive for the UI to display an error immediately when the field gets updated and the valuidation rule runs. Is there any downside to this? Would it be a better design to do the validation when the object is being saved? If I do end up connecting to the database from the validationrules, then I'm going to be executing a CommandBase object to return the results. Any thoughts on this design?

pelinville replied on Wednesday, July 19, 2006

I wouldn't do it simply because it could make the objects more complex.

Another thing is that it could slow things down a whole bunch. Everytime one of those values changed you would have to go back to the database. Add in a remote setup and the UI becomes very unresponsive. (Unless you do some fancy thread stuff. I tried this and the comlexity introduced far out weighed the benifits.)

I find it better and acceptable in almost all situations to check these things in the Overridden Save. If for nothing else because users expect a delay when saving so this wouldn't cause as much frustration.

One suggestion I have is you create a class that is responsible for the checking and don't put this code in the BO itself. This 'validating' class would take one or more of the objects to be checked and then mark the invalid ones. The 'validating' class could also return the objects that already contain the unique valuse giving the user some context to decide what to do. This keeps your original BO as simple as possible.

RockfordLhotka replied on Wednesday, July 19, 2006

This has been discussed before, and the key thing to remember is this: any validation you do prior to the actual save operation is not meaningful. It is, at best, a service to your user that you are making a best-guess that their update might work.

But you never know for sure until the actual save is in-process, transactionally, on the server. Well, unless this is a single-threaded, single-user application Big Smile [:D]

All that said, sometimes it really is nice to give the user your best guess as to whether the update might succeed. Users like that stuff. Just don't forget that you also need to do the check during the update itself.

DansDreams replied on Thursday, July 20, 2006

Just to possibly clarify a bit what Rocky said... that kind of thing is often going to be constraint right in the database to accomplish the requirement that it ultimately be checked as part of the save. You could do it in the business layer in a transaction, but it's probably not advisable for performance reasons.

cultofluna replied on Sunday, August 20, 2006

Hello,

I'm having a problem similar to this. I have an Element that has an unique ID that is provided by the database. The Element also has a keyword that must be entered by the user. This keyword also has to be unique. In my database I've set a PK on the ID and a SK on the keyword.
But how should I handle whether or not the keyword is a duplicate? Shoud I handle the exception from the DataPortal and analyse the error returned from the database? Should I perform a check just before the DataPortal update for the duplicate keyword?

What is the correct way to solve this in the CSLA?

Best regards,

david.wendelken replied on Monday, August 21, 2006

If you are accessing the data via an editable collection (as in Role and Roles in the ProjectTracker sample application), check out the sample NoDuplicates rule in Role.

A check "just before" the dataportal update isn't guaranteed to work, because another user in a multi-user system could add it "right after" you check and "just before" you issue the update.

RockfordLhotka replied on Wednesday, August 23, 2006

The NoDuplicates rule is part of the 2.0 version of ProjectTracker - but it is just an example of a custom rule method.

Version 1.53 has comparable functionality in terms of building rule methods, and so the same technique should work for you.

Rocky

From: cultofluna [mailto:cslanet@lhotka.net]
Sent: Tuesday, August 22, 2006 4:50 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Using ValidationRules that Query the Database

Thanks for your answer, however is this in CSLA 2? I'm using 1.53, but I can't seem to find the rule NoDuplicates...
Could you tell me where to find it?