>Hope you don't mind if I jump in.
>
>>If say, the client wants to create a new USER, the client calls the AddUser() method in the BO, then the BO calls the AddNew() method in the data-object, but, what form should the initial information passed around be in?
>
>That's actually a great question, IMO, and the answer isn't obvious, nor is there only one correct approach. I think it's important to know just what kind of boat you're building. So, keeping in mind business validation *could* be done, conceivably, by pinging a webservice on an intranet, or they could be encapsulated in a DLL.
>
>In my mind, a business object will "mirror" the representation of the data. So, for example, you might have a business object with a collection property that represents rows of data (but is detached from the data, of course). You're UI could instantiate your business object and then bind to it's data. You can do it any number of ways. For example:
>
>

DEFINE CLASS MyCustomer AS CUSTOM
>  Lastname = ""
>  Firstname = ""
>  SSN = ""
>  PROCEDURE Set(tcAttribute, t_Value)
>    STORE t_value TO this.&tcAttribute && you might check for errors of course
>  PROCEDURE Get(tcAttribute)
>    RETURN this.&tcAttribute
>  PROCEDURE VALIDATE
>    *!* For each attribute (field) do something like:
>    RETURN THIS.ValidateSSN()
>  PROCEDURE ValidateSSN()
>    RETURN !EMPTY(THIS.SSN)

>
>Then, your UI could bind controls to the business object's propreties, although that's not very flexible if the data changes, or it could pass the data to the business object thru the SET(). In either case the data is _not_ XML or ADO format at this point. You're talking object to object properties.
>
>The data object would talk to the _data_ via ADO or XML. The Business object *might* talk to the data object via XML, though I wouldn't personally design it that unless the system demanded it. Too much overhead if you don't really need it.
>
That sounds visable enough. If that was implemented, I could call the business object to switch records, which in turn will update the properties, and then display the records data.

This would also deter the need for the knowledge of what the fields names are in the tables, as the properties would be self explanatory.

Although, saying that, for some reason, I was thinking of passing recordsets of data around, and have the controls bound to them, then pass them back for saving/undoing to the business object.

It's a real rat's nest, IMO, I'm having second thoughts about going in this direction already.

Thanks for your help, it is appreciated.

Kev