BorlandTalk.com

Bruce Wood · Guest

I'm new to this group, having discovered it via Joanna Carter's posts
to microsoft.public.dotnet.languages.csharp. So, my apologies if this
has already been covered here.

I'm up against an interesting design problem that doesn't seem to be
covered in the GoF book or any other resources I have.

We have a complex business entity (in this case a SalesOrder) that is
related to a lot of other things in the business, and so can have an
enormous amount of information associated with it. It exists in two
tables in a header / detail (sales order / line items) relationship,
but there are myriad other tables that provide auxiliary information
(such as six more tables describing Goods in Transit, etc. etc.)

Our first crack at writing classes for SalesOrder was to say that we
would always read a complete sales order: we would never have, for
example, a sales order with only some of its line items. So far, so
good.

However, as we use SalesOrder in more and more applications, which need
to see more and more aspects of a sales order, the class is becoming
more and more bloated, and more and more expensive to fetch from the
database. Things are beginning to get out of hand.

Can anyone point me to a design pattern that will optimize "lazy
fetches" of information of this type? What I'm hoping for is some
construct that will allow an application to fetch only the parts of the
sales order that it's interested in, either by specifying the items of
interest up front, or by a "lazy fetch" that gets a basic sales order
first and then goes back to the database for more information as the
caller asks for properties of the object that haven't yet been fetched.

The latter was my first reaction to solving the problem, but of course
this introduces massive overhead as well, as the data layer makes
multiple trips back to the database to fetch added aspects of each
sales order on demand. Yuck.

Any ideas on how to solve this problem, knowing that fetching
"everything" up front is becoming thoroughly impractical, and any
"lazy" solution must take into account that queries into the database
for further information are expensive and so must be kept to a minimum?