>If I create a customer object with the ui, a customerbiz object and a customerdat layer that is self contained basically, does that violate this principle?

There should be no UI in a business object. Beyond that you can always use delegation from a higher level to access the business object.

+++ Rick ---



>
>
>
>>You defintely don't want scenario one because that's coupling your UI to your business layer. You don't want that for sure. The whole point of the business object is abstract all business logic away from the UI.
>>
>>You can however build a generic form class that knows something about your business object. So it could have methods like Save, Load etc. that can pre/post process operations against the business object. For example, on a Save automatically pop up error messages or ask whether you want to save etc.
>>
>>OO more than anything is about isolating logic to the appropriate object.
>>
>>+++ Rick ---
>>
>>>I am trying to determine the correct way (in the consensus) of doing the following. I am vacillating between 2 scenarios:
>>>
>>>1. Create class customer, customerData, frmCustomer, frmCustomerList. From main menu of main app instantiate customer and inside customer instantiate customerData. Have method to show forms when needed, have form function calls point to methods in customer.
>>>
>>>2. Create same classes, but have main menu instantiate form as needed, and in form class instantiate customer (which instantitates customer Data) and have function calls point to customer methods.
>>>
>>>Which would you suggest? Why?