>>>>>I have a customer record, which has one or more account records. Each account can have one or more invoice headers, each with one or more invoice detail records. I wrote a class for each.
>>>>>
>>>>>When I create an instance of a customer class and call LoadCustomer, should that process also create a collection of accounts on the customer class. Then, should each account create a collection of invoice headers, which in turn would create a collection of invoice details?
>>>>
>>>>I'm assuming you're talking about DataSets? This is the area where DataSets got a little fuzzy for me (I admit it's probably from my own lack of knowledge) and it why I switched to custom objects.
>>>
>>>Not necessarily DataSets. I'm pulling the customer data into a DS, but then I copy the data to properties on the class My Customer class has an Address collection, and when I load the customer's data I also load a collection of addresses. These addresses are classes with properties for the address data.
>>>
>>>The question really is: Is it a good idea to create hierarchies of classes? I have always heard "Pull what you need, need what you pull", so if I create this cascading data class hierarchy, I could end up with a bunch of data in classes that I might not use on each call.
>>
>>Personally I like having one call available that will bring back ALL relevant info for ONE customer (assuming they're not likely to have hundreds of invoices or thousands of lines) . Obviously it is not suitable for all purposes but other calls can be used for narrower requirements.
>
>
>I came up with a solution.
>
>Each class has various collection properties. The Customer class has an Invoices collection, and the Invoices collection has an Invoice Details collection.
>
>In the Get of the property of a given collection I call the method to load the collection. This method is public, so I can always call it load/reload a collection, but if it is never accessed, then it is never loaded.

This is Lazy Loading. It's a popular design pattern for what you are doing.