I have a parent EditableRoot with a EditableChildList. I don't know how I've not noticed before, but I see that BusinessListBase does not have a BrokenRulesCollection Property, but it has a IsValid Property.
How should make my Object design translate broken rules from the children of EditableChildList all the way to the Parent? How is this typically done?
I'm thinking about doing this with a custom rule in the Parent Object. Does anyone have a better (or more conventional) solution?
public
static bool ChildListRules<T>(T target, Csla.Validation.RuleArgs e) where T : MyParent{
if (!target._myChildList.IsValid) foreach (MyParent info in target._myChildList) foreach (BrokenRule rule in info.BrokenRulesCollection)target.BrokenRulesCollection.Add(rule);
return true;}
If this was appropriate, I would think BrokenRulesCollection would have been designed with a AddRange()...
Ugh, someone please stop if there's a better way to do this:
In order to notify the parent that the rule needs to be checked, I am going to add a ListChangedEventHandler in my parent. The property accessors of the list's children should prevent superfluous calls to this event I think... And the DAL turns off RaiseChangedEvents for the list....
this
._myChildList.ListChanged+=delegate(object sender, ListChangedEventArgs e){this.PropertyHasChanged("MyChildList");};
Doesn't something like this already exist in the CSLA framework to provide BO Validation for this scenario? Sorry if an obvious answer exists, I just can't find it.
I'm trying to accomplish:
A root object that is valid, only if a child (EditableChildList) is valid. If it's not valid, then I need the Parent's BrokenRulesCollection to contain the rule that is broken.
The point, is to make a BO design that abstracts a lot of the work for the UI developer... so that they don't have to manage mutiple BO's and manage the validation separately, instead all validation can be managed from the Parent...
In regards to my attempt above, unfortunately, it seems that I cannot make this call because BrokenRulesCollection inherits ReadOnlyListBase and cannot perform the .Add(rule):
BrokenRulesCollection.Add(rule);
Exception: "Insert is an invalid operation" at Csla.Core.ReadOnlyBindingList`1.InsertItem(Int32 index, C item) in C:\dotnet2005\projects\csla3.0.5cs\cslacs\Csla\Core\ReadOnlyBindingList.cs:line 87 at System.Collections.ObjectModel.Collection`1.Add(T item)
I've dealt with CSLA for a while now, and would be surprised is this functionality doesn't exist already somewhere, I just don't know where to look.
The reason CSLA work as it does, is that each object is responsible for itself. One object can't be responsible for another object, as that would break encapsulation. So each object maintains its own list of broken rules.
Consider what would happen if the root had 100 decendents (children, grandchildren, etc). The list of broken rules for a root could be dozens or hundreds of items. None of which are about the root. That'd be a total mess.
However, in CSLA 3.5 and higher (I think it was 3.5) you can create your own BrokenRuleCollection objects, and you can copy the data from existing collections into your collection. Basically I provided the base mechanism by which you could create a "master list" of all the broken rules for all the properties of all the objects in an object graph if that made sense to you.
I don't actually DO this, because I'm not convinced it is a good idea. But several people wanted to do things somewhat similar to what you describe, and so I enabled the scenario. You just have to write an internal method in your collection object to build and return the BrokenRulesCollection that combines all the lists of rules from the children in the list.
Cool, thanks for the incredibly insightful response (as usualy). I'm really interested in the encapsulation philosophy and would love to read more about what you're describing. Might you have any articles that you could point me to on the topic that relate to this situation that you recall? I would greatly appreciate any educating I can get.
Thanks a million Rocky!
Copyright (c) Marimer LLC