Help with largish object hierarchy

Gannet posted on Thursday, April 26, 2007

I have a project we've been working on for a while now.  We used C# and CSLA 2.0.  It's our first CSLA project, although I did mess about with an early version of Rocky's ideas back in the "Visual Basic 5 Business Objects" days.

Everything went fairly smoothly when using small sets of data.  But as we scaled up to production volumes, performance problems arose.

Specifically, we have something that looks like this:

An Outage has a collection of Steps, each of which has a collection of Transformers, each of which has a collection of Premises.

As to volume, one Outage has about 1 to 5 Steps, each of which have 1 to dozens of Transformers, each of which has one to dozens of Premises.  In a worst-case situation one Outage has about 5,000 Premises.

In CSLA terms, we have this:

Outage - EditableRootParent
has a
StepList - EditableChildList
contains
Steps - EditableChild
each has a
TransformerList - EditableChildList
contains
Transformers - EditableChild
each has a
PremiseList - EditableChildList
contains
Premises - EditableChild

Using the normal CSLA model of having the Fetch of the EditableRootParent get all the data for all the children is, not surprisingly, quite slow if this particular Parent has a lot of great-grandchildren.  The thing is, we normally don't need all the children.  We only need them if the user wants to drill in via the GUI to manipulate the children.  Even when he does that, we normally only need to manipulate particular subsets of children.

So.  I'm sure we're somehow doing this wrong.  I know what I would do with our old-style less-rigorous object architectures, but I don't know how to handle it with the DataPortal. 

How can I do "partial" or "as-needed" data retrieval of children/grandchildren/great-grandchildren?

Or does it look like our basic object model is wrong?

Any help appreciated.

RockfordLhotka replied on Thursday, April 26, 2007

Given your description of the user experience, I'd suggest that you are merging a set of different use cases into one big use case, and the result is that you are creating one big object hierarchy, where you should actually have a set of much smaller, more focused, object hierarchies.

Remember that objects aren't driven by data, but rather they are driven by the application's requirements in terms of functionality and behavior (the use cases).

In a long-winded way I'm suggesting that your object model is wrong.

Bayu replied on Friday, April 27, 2007

A more specific suggestion to augment Rocky's post:

View 1: - Outage with Steps
- create editableroot Outage, the Outage can be edited in itself, independently of any children
- create readonly list StepList with readonly StepInfo objects, to be displayed in the same view
- when the user 'drills down; to a particular step, like you explain in your descripiton you get to the next view ... -->

View 2 - Step with Transformers
- create editableroot Step which can be edited independenly, like Outage it has NO editable children
- again a readonly list: TransformerList with readonly TransformerInfo objects
- double click on a particular TransformerInfo will drill-down further just like in the Outage view

View 3 - Transformer with Premises
- you get the idea ...



This is just to give you an idea. The following benefits will result from a setup like described:

1 - you only fetch what you need, a dozen or so records at a time (Outage + Steps or Step + Transformers or Transformer + Premises)

2a - in my suggestion there is only 1 editable object per view (the root object), all children are readonly lists. This will give you another performance boost as the readonly objects are rather lightweight when compared to the editable version

2b - if you find that you need an editable root with editable children in order to have a view functioning according to your requirements then that is fine too. Simply skip the readonly lists and work with editable children as you do now. Since there are still only a dozen or so editable objects per view it should still perform perfectly fine. Note though that instead of your current 4-level hierarchcy of editable objects you will then only have 2 levels (root + children) at a time.

Hope this helps.
Bayu

Gannet replied on Monday, April 30, 2007

Thank you both for the replies, they are indeed helpful.  Special thanks to Bayu for taking the trouble to show me an alternative example.  I'm the sort of fellow who has a hard time learning other than by example.

I've read on the forum here many times that letting the data dictate the object model is incorrect, but I'm having a hard time wrapping my head around what other way there is to do it.  Suggested readings appreciated.

I'm starting to try and wrap my head around just how I would deal with things in Bayu's model.  I may be back with more questions.  )