David-

>If I understand you correctly, your business object has both a collection of data rows and a property for each data field.

Well, no, but I can see that my writing wasn't terribly clear on that.

>My only problem with this approach is that the business object is doing double duty and it makes for some serious OOP limitations. For example, your customer object may contain serveral customer records which you expose at certain times through properties of the object.

No, in the context of the current discussion, the customer business object will deal with one customer at a time. I could see a customers bizobj that would have a collection of customer business objects. The collection could have how many different sorts of custumer objects as the system needs. But I'd only have that if there was some reason for running business logic on a dataset as a whole. (And there isn't necessarily a reason to, that I can see.)

> Now, what if I want to subclass Customer into CorporateCustomer and IndividualCustomer and these different subclasses have different behaviors?

You'd, um, subclass customer. ;-)

>There is no way to do this elegantly with this design since there is only one object that must contain both behaviors.

Er, no. I don't see why that's a necessary conclusion.

> You end up with a lot of IF and CASE statements instead of using polymorphism.

Yuck. I'm sure we both try to avoid methods with branches.