Vin

Just one more thing I need to get over now, the front-end. If the front-end (VFP) receives ADO or XML is it best to convert this data into a cursor? Will the front-end require some sort of data-handling of its own?

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).
>>
>>Thanks Vin, I've heard alot of pros and cons to using XML/ADO, the only reason I wouldn't go XML is due to large recordsets, but at the moment I can't think of any large amounts of data that will be passed around, so I may consider it.
>>
>>So from what you're saying, let the business talk to presentation via XML, and the business talk to data via ADO?
>>
>>Thanks
>>Kev
>
>
>Yes, under the scheme I consider that is what I am saying - but see Craig's post for the democratic response :) ... I prefer to pass XML if I'm moving across multiple servers, but Craig certainly is correct that there's a cost associated with constructing the XML, so it will depend on your situation.
>
>But having given those disclaimers, here is a rough outline of what I tend to do... it's just one of many possible routes you could go:
>
>-- Business layer uses ADO to get data from database in form of a recordset;
>-- Business layer constructs XML stream and closes ADO connection;
>-- Business layer passes XML to presentation layer;
>-- user actions --
>-- Presentation layer passes XML to business layer;
>-- Business layer validates information as necessary;
>-- Business layer constructs SQL Statements (INSERTs, UPDATEs, DELETEs as required) or, business layer prepares calls to stored procedures (which I like even better actually);
>-- Business layer establishes connection to database and executes SQL Statements;
>-- Business layer checks for errors, etc., and takes appropriate action and/or passes error info to presentation layer.
>
>I've always preferred to update data via stored procedures (rather than direct ADO RS field value changes), so that's another reason that I tend to like this approach. But as I have said, it's just one possible approach. if you are using VFP remote views, you will have a whole other range of possibilities, of course. And then there's always RDS (which I don't recommend, for security reasons).
>
>PS -- There's another approach I have used, as well, which is much quicker than XML -- the ADO GetRows() method. This returns a delimited string of data (you can specify delimiters between field values, and also between rows). You can then pass this string to the presentation layer and parse it out as necessary. GetRows is very fast, so it avoids the slow construction of the XML string. But, it does have a drawback -- your presentation layer will need to know the structure of your data! (In other words, it will need to know that the third field is "last name" or whatever). You end up with tightly coupled front and middle layers, which generally is a no-no. But, I'll tell you, the speed of this approach is pretty impressive. But I don't like the tightly-coupled aspect of it: so, for instance, I would not do this in a situation where you have separate developers working on the presentation layer and the middle layer...