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)
I posted a generic class code to do this here: http://forums.lhotka.net/forums/post/23717.aspx
Feel free to use / modify it as you see fit.
Sergey Barskiy
Senior Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: rsbaker0
[mailto:cslanet@lhotka.net]
Sent: Friday, July 18, 2008 6:04 PM
To: Sergey Barskiy
Subject: [CSLA .NET] General strategy for reporting broken rules from
child object via root?
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".
Similary, 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?
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)
Copyright (c) Marimer LLC