CSLA .NET

What is the recommended approach to allow for the consumer of a root object to know what is broken when the broken rule is in a child?

It's easy enough to implement IsValid() so that this validity is properly handled, but if the consumer of the root object decides to test IsValid() first, the BrokenRulesCollection of the root object will be empty, so there isn't anything useful to display except "Sorry, it's broken".

Similarly, if the root object is throwing an exception because you called Save() and it isn't valid, the root doesn't know at that time which child is at fault.

Are we supposed to reimplement some sort of traversal of the object hierarchy to locate the offending child, or is there something in the framework that will help?  (CSLA 3.0.x)

 

Thanks! This certainly will help me get what I need.

I think what I'll do is use your logic to implement a "BrokenObjectsCollection". That allows the consumer to have a little more control over how the error is handled.

 

Ouch!

It turns out that if you traverse the hierarchy using Properties, then lazy-loaded collections get loaded when the the property value is accessed.

I could access the backing fields themselves instead which would avoid this problem, but I'd be concerned about partial trust issues since these fields are private.

Can a member function of a class reflect on it's own private members without trust issues?

rsBaker,

Not exactly sure if this is something you're looking for but I posted an example of working with broken rules for nested child objects. I do not handle the lazy loading case but check it out and hopefully it helps.

John

Thanks! I think this will be very helpful.

I solved the lazy loading dilemma using a new attribute that indicates if the property lazy-loads the collection. Unless the attribute is present and explicitly set to false, I don't recurse into that property when enumerating broken rules. I'd prefer a more general solution, but I can make this work.

Randy

 

I posted some code for how I do this a long time ago.

The key is that the list of "owned objects" (and collections) is filled by traversing the Fields not the Properties. This effectively bypasses any lazy loaded properties.

Joe

 

I can certainly do this, but I didn't know if there were trust issues since the fields were private. Of course, .NET could be smart enough to let an object reflect on its own private fields, but I would think private fields of child objects could present a trust issue.

(I'm a newbie at trust issues, though, so this is speculation and it would be nice if someone new definitively whether this was a problem)