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.



> I know ADO and XML are the forms, but what about identifying which values go in which fields?