Ordered BO list

Ordered BO list

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


ajj3085 posted on Monday, January 12, 2009

hi,

I'm converting some code to use the newer PropertyInfo capabilities in Csla.  I ran across something I'm not sure how to handle.  The BO is a BLB subclass, and when saved, the items in the list use their position within the list to save their order.  The old code is like this:

        internal void SaveSelf(
            Data.Quoting.Product parentProductData
        ) {
            PositionCounter counter;
            bool raiseEvents;

            if ( IsDirty ) {
                raiseEvents = RaiseListChangedEvents;
                RaiseListChangedEvents = false;

                foreach ( BundleItem item in DeletedList ) {
                    item.DeleteSelf();
                }
                DeletedList.Clear();

                counter = new PositionCounter();
                foreach( BundleItem item in this ) {
                    item.SaveSelf(
                        parentProductData,
                        counter
                    );
                }

                RaiseListChangedEvents = raiseEvents;
            }
        }

PositionCounter is just a class that has a method called GetPosition, which returns the current int value it stores than increments it.  The child class calls it in it's data routines.

The problem is that Csla now iterates the list, so I have no way to create and send the instance.

My current thought is just to have the child item get the list via Parent, and then calling IndexOf.  Does anyone see any issues with this?  What about other ideas?

Thanks
Andy

skagen00 replied on Monday, January 12, 2009

If you're using Child_Update, I had a scenario similar to this. It had to do with code maintenance - codes don't change too much and here isn't much to them, so the solution isn't highly performant - but that's OK because the frequency of use is very low.

I did an override of Child_Update in the BLB and looped through the children setting their sort values (I believe its an internal property) to their index, and then did base.Child_Update. (which took it from there)

I don't know if that's entirely identical to what you're attempting to do, but it sounded familiar. Obviously, in the event an item is inserted into the middle, it will force an update on potentially all of the codes (if inserted at position 0) -- but like I said, since it's a low frequency event and the objects are tiny, I wasn't too worried about it.

Chris

ajj3085 replied on Monday, January 12, 2009

Ok, thanks for the feedback.  It sounds like I might be on the right track then.

SonOfPirate replied on Monday, January 12, 2009

We ran into something similar (and had hierarchy too).  Someone I worked with did a performance test and found that, in our case, it was actually more performant to update the indexes as properties on each item whenever an applicable change was made to the list (add, remove, move) rather than iterate through the whole list each time we needed to re-index (on save in your case, I guess).

In our case we had long lists and, as I mentioned, a hierarchical component, and changes to the list itself were far less frequent than changes to the list items.  Trust me, the logic wasn't the simplest but it did work out for us.  For an incremental cost when an item was removed, inserted into the middle of the list or otherwise moved, we saved a ton not having to lookup each item's position as we iterated through to save.  We basically spread it out rather than incurring it all at once.

Something to think about.

 

daniel_higgins replied on Monday, January 12, 2009

why not override the ChildUpdate and use a

for(int x=0; x< this.Count; x++) DataPortal.UpdateChild(this[x], parameters, i);

in the middle of your override. The current code in BLB UpdatChild is pretty much the same as what you used before.

I've noticed that BLB has a lot of logic for maintaining Indices and PositionMaps. It might be that calling up to the parent from the child object, as you've considered as an alternative, might be very fast.

Copyright (c) Marimer LLC