David-

>Exacltly my point. There is no single "business object" for customers. You have a Customers collection class and Customer single entity class. A better example would be an Order class which would have a reference to a LineItems collection class which would contain LineItem entities. The Order object would have to run through its LineItems collection to get the current order total, for example.

Yeah. That would be an approach.

>But who decides which subclass to instantiate? Which is the "business object", the collection/container or the entity? Which has responsibility of loading and saving the data?

Simplisticly I'd have one business object for each entity. Some entities are composites of other entities. I'm really not following your conclusions you draw about my _example_ of what one of these beasts could look like. Maybe if you mocked up a little outline of your idea of an order/invoice example, it would help me understand your conclusions.

> You could say the collection has the responsibility of loading the data since it needs to determine which subclass to instantiate.

I supposed you could, though I wouldn't.

>But then what about saving the data? What if a CorporateCustomer has different business rules and behavior than IndividualCustomer? So you put the Save on the Customer entity. Now you have a different object doing the load than the object doing the save, encapsulation is broken.

Huh?