Databinding killing performance

ajj3085 posted on Friday, October 12, 2007

Hi,

I have a winforms app and a screen that edits a quote, or invoice.

My problem is that databinding and property changed events are making things really slow.  I am fixing some of it; for example, operations which delete multiple lines or group multiple lines, I turn off RaiseListChangeEvents on both the BindingSource and the collection itself.  that seems to help a bit.

Other areas though include adding a single line.  In my case, the Quote object has a Total, SubTotal, and Tax, which if a single line is added, those are changed.  The Quote listens for a ListChanged event from its Items collection, and raises property changed event for the Items property itself.. that seems to cause it to requery the totals fine.

I'd like to speed things up a bit more.. any ideas? 

Oh, another thing.  I have three Contact (sold, ship, bill) properties on the Quote which are also BusinessBase objects.  These objects in turn contain three more objects (one for address, two for phone / fax numbers).  The Contact object though uses a facade to hide the Address and Phone classes, but the Address and Phone classes still call PropertyHasChanged (to get rule checking and dirty flagging).  Should I change the hidden classes to just do rules and dirty manually, and have the Contact class raise the propertychange on its own?  The Contact property listens to its child objects and raises the appropiate property changed on its behalf... but i'm thinking that perhaps its more efficient to just have the contact object do that part? 

RockfordLhotka replied on Friday, October 12, 2007

Are you sure your object model reflects your use case? While sometimes you do need UI helper objects to reshape a business object model, more often than not, a business object model will be very close to the UI's requirements, because both the UI and objects were created for the same use case.

In other words, why do some of your objects have sub-objects? Do they exist due to the requirements of the use case? Or due to the shape of the underlying data? If the latter, your object model may be overly complex.

ajj3085 replied on Friday, October 12, 2007

Well, the use case is like this.  product bundles must show on the grid each product which makes up the bundle.  You can't do anything to the items that make up the bundle, but you can change the price of the bundle itself and move it up or down on the list.  If its moved up or down, all the sub items most move as well and stay in the same order as they originally were added (bundle item order is specified by the product administrator).  Also, users can create ad-hoc bundles by grouping non-bundle items together. 

When a bundle is removed, all the items must go with it.  Items in a bundle can't have their order changed.  Groups are similar, except you can take a sub item out of the group and it should be added back at the end of the list.

Additionally, depending on which form is printed, sub items must be shown or hidden.  Basically, customers shouldn't see sub items, but internally we have to.

So perhaps my object model is screwy, but I'd still have problems with a flat list, keeping the sub items together and indivisible and such.

Also, some of the slowness is not related to the line items at all; its related to other parts of the document (sold to, ship to, bill to).