>Hi, Mike.
>
>>>we deal with similar design here and the approach we use is to have multiple select statements in sprocs and readers to populate collections etc.
>>
>>Maybe I was fragmenting the flow too much.
>>
>>Sticking with my example, when would you load the different entities?
>>
>>Let's say we are going to bring up an alphabetical list of vendors, and we are going to click on the vendor and "zoom in" on their PO history. Are you going to load all vendors, their POs, and all line items once? Or are you going to load a list of vendors and later load a certain vendor's POs when they are zoomed in on?
>
>What you need here is an architectural pattern called Lazy Loading. Basically, you can have your Vendor class with a PurchaseOrders collection, but you don't load the POs when you load the Vendor itself, but you check whether or not the collection is populated in the property get: if it is not loaded yet, you load it (maybe with some filtering scheme), if it is loaded already, then you just do nothing.
>
>Now, the advantage of that is that when writing your business logic you don't need to worry about whether the collection is loaded or not; you just access it as it is always available.
>
>Of course there is a ton of things you can do around that. You may not want to make all your composites Lazy, because there could be some that you want to get in a single rountrip (each lazy load is an additional one), so you may want to have a way of selecting how it works in your Entity abstraction (maybe with some custom attributes).
>
>Hope this gives you some ideas. We can delve a little more if you need, and maybe write some code here later.
>
>Regards,

Martin,
I have seen this used before in a few apps I maintain, but I didn't know it was an actual pattern - I thought it was the developer doing something quirky and never looked at it again. I will check it out, but it sounds about right.

Thanks!