Print Page | Close Window

Recursive validation

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=854
Printed Date: 26-Apr-2024 at 6:23am


Topic: Recursive validation
Posted By: Jason
Subject: Recursive validation
Date Posted: 25-Jun-2008 at 7:42am
Good Afternoon
 
I was wondering if anyone would be able to help me with the following problem
 
I am using the full version of Devforce v3.6.2.2 and VS2008 (c#)
 
I have three entities mapped to a normalised database - Customer, Address and Country.
A 1:1 relationship between Customer and Address exists.
A 1:1 relationship between Address and Country exists.
 
I'm implementing verification into a project which has been built around the ideablade CAB model.
 
I am able to verify the Address and Country entities by creating a method within the Customer entity and hooking it up using a method which is decorated with the VerifierProvider attribute
 
My question is whether it is possible to validate recursively so I can just put attributes on the relevant fields in the child entities and then just validate the parent entity? There is so much to the CAB project that I don't know if I'm missing something obvious?
 
Thanks
Jason



Replies:
Posted By: davidklitzke
Date Posted: 26-Jun-2008 at 1:35pm

The short answer is “no … there is no recursive validation; no there is no CAB or Cabana magic to exploit (that I can think of).”

 Given this structure I would be tempted to extend the Customer object with Address and Country properties that reach across to the dependent objects … in essence, I’d flatten this out from the Customer object consumer’s perspective.  I’m not sure if this is the right path … it’s dangerous if there are other routes to the address or if you allow people to modify Country. But, assuming this is ok,  I’d add validations to those custom properties and you would bind to “aCustomer.Street” rather than “aCustomer.Address.Street”.

Of course you also have to manage this Aggregate … you have to make sure any change to the address is also a change to the parent customer (for concurrency purposes) and then save them together when you make a change in the address. 

I’m speaking really fast here and gliding over theory and details.

I would also reconsider if this kind of thing was happening EVERYWHERE. In that case, I’d want to look at a more generalized approach.

Anyway, this is a short peek into the matter and, if it shines adequate light on the path great; if not, we can refine.

 



Posted By: jeffdoolittle
Date Posted: 27-Jun-2008 at 9:13pm
If you're doing instance level verification, you could set the related entity's DataRowState to modified, and then make sure you verify all "modified" entities in a Persistence.Saving event handler.
 
--Jeff



Print Page | Close Window