New Posts New Posts RSS Feed: Recursive validation
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Recursive validation
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
Jason View Drop Down
Newbie
Newbie
Avatar

Joined: 04-Feb-2008
Location: United Kingdom
Posts: 5 		Post Options Post Options   Quote Jason Quote  Post ReplyReply Direct Link To This Post Topic: Recursive validation
    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
Back to Top
davidklitzke View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 14-Jun-2007
Posts: 715 		Post Options Post Options   Quote davidklitzke Quote  Post ReplyReply Direct Link To This Post 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.

 
Back to Top
jeffdoolittle View Drop Down
Senior Member
Senior Member
Avatar

Joined: 14-Jun-2007
Location: United States
Posts: 146 		Post Options Post Options   Quote jeffdoolittle Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down