>>>
>>>>If I'm working with ADO I find it very confusing being in a 3-tier app, if I had the UI working with ADO recordsets, that are based on tables in the data-tier, isn't that creating a direct-link between the UI and the Data? Or have I got this method of working wrong?
>>>
>>>I don't know how sophisticated this is, but in my mind ADO recordsets are a data layer, sorta. As are stored procedures. If a UI talks to an ADO recordset then that's a client/server, or 2 tier model, right? You're bypassing the business layer. But you haven't coupled data with the UI. (The ADO is inbetween.)
>>
>>I don't see ADO as two-tier because the ADO can easily be passed through multiple components, unlike a View or SQL Pass Through. I see ADO as a way to pass the data.
>
>I suppose it will depend how the presentation layer is actually reading/writing the data, if it is directly to an ADO then surely this will be going directly back to the data-layer.
>
>I think this is where I'm getting confused. The way I'm picturing it is the presentation layer receives an ADO from the business-layer, changes are made to some of the fields, then the Update/Cancel methods in the ADO are executed from the business object (upon validation), is that how it would work?
>
>Thanks
>Kev

To be honest, I'd recommend against passing the ADO objects -- consider passing XML instead. Then, pass XML back to the business object after the user has entered data, construct your INSERT or DELETE or UPDATE statements in the business layer, and send to the database (probably via ADO calls).

The reason I'd recommend against passing objects is that the overhead is much heavier especially if you have the presentation and business objects on different servers (likely, in a web environment).