Biz rule for duplicate children in collection (CSLA 1.53)

Biz rule for duplicate children in collection (CSLA 1.53)

Old forum URL: forums.lhotka.net/forums/t/1288.aspx


etterre posted on Wednesday, September 20, 2006

Hey,

   I hope that someone out there has figured out this problem before - I've searched the old forum and this one and I seem to be coming up empy. 

How can I "best" use the RuleManager/AddBusinessRules flavor of business rules to enforce a "no duplicate child in a collection" type rule?  I can see how I could put an "instance type" rule on the collection and keep it to O(n) for each call to the rule.  But I want the rule to be broken on all the affected children so that it's easy for the user to see which children are duplicates of each other.  Most of the things I can think of get rather expensive...

My particular situation has a requirement that the particular combination of 3 properties on a child BO should be unique for all children in the collection.  I also need to be pickier and have the rule "unbreak" no matter how it gets resolved (deletion of original, modification of a property on the original, deletion of dupe, etc). 

At the moment we're "stuck" with VS2003 and VS2005 is probably 6 months to a year away.  But I'd like to keep my code reasonably compatible with some of the changes in CSLA 2.x since we could be standardizing on VS2005 "soon" and I'd like the port to be as painless as possible...

Unfortunately my first whack at this problem uses BrokenRules.Assert calls as shown in the attached file (attached as combined.txt, split and rename to .vb) - and I know that those are going away... 

I've tried to keep this short - let me know if more info would help.

Thanks!

skagen00 replied on Wednesday, September 20, 2006

I've done something like this really similar recently.

Since the collection has the "perspective" with which to validate/invalidate, I capture when the collection changes in a way that may affect the result - row inserted/deleted or onlistchanged when a particular couple properties change.

It is then the collection which has a validity checking method to survey the members to determine which (if any) are in an invalid state. I then have the collection communicate via an internal set property (get is public) of its members for whether the Seasonal info is valid for each particular member.

A validation rule then exists on the child members directly on the IsSeasonalValid - which is a rule that simply ensures it's true. If it's false, it's considered a broken rule. To me this works very well.

In my case, there are only a few members to check (less than 5). If you have a lot to check, perhaps it gets to be tooexpensive - perhaps you maintain a dictionary on the collection for the various item types in the list so that you can easily survey whether a change in the list breaks one or more records and be more efficient with the validity/invalidity setting.

 

 

skagen00 replied on Wednesday, September 20, 2006

I have to mention that I didn't notice until just now your question was with CSLA 1.53. I suppose a similar approach could be taken but not having worked with 1.53 I'm afraid I can't help you with that.

RockfordLhotka replied on Wednesday, September 20, 2006

The basic concept you are using should work in 1.53 as well. Version 1.53 includes the automatic hook-up of IsDirtyChanged for all child objects by BusinessCollectionBase, and so the tools should be there to implement what you are describing.

Copyright (c) Marimer LLC