Hey Craig.

Re:
>Are you saying your business layer is handling database
>connections, etc? Wouldn't this be better off in a data layer?

I did not express myself well in that previous post -- I do use datalayer objects, which are called by the business layer. In my bullet-point list in my previous post, I was folding all of this under the "business layer" since I was mainly concentrating on presentation versus business layers.

Re:
>Establishing the connection is VERY expensive. Do you host your
>biz objects live in COM+ where connection pooling can be reused?

Yes, I do. Another point I should have mentioned explicitly....

Re:
>I recommend against views as they are a two-tier solution.
Me, too. But I suppose that a data layer could encapsulate a remote view, right? In other words, send data from the presentation layer-->biz layer, and from there pass to a data layer that creates a remote view and applies updates etc.

Again, I've never done this -- I haven't really worked much with remote views, period. But what do you think?




>See my comments interspersed.
>
>>
>>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;
>
>Are you saying your business layer is handling database connections, etc? Wouldn't this be better off in a data layer?
>
>>-- Business layer constructs XML stream and closes ADO connection;
>
>Establishing the connection is VERY expensive. Do you host your biz objects live in COM+ where connection pooling can be reused?
>
>>-- 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);
>
>I agree. Stored Procs are a good idea.
>
>>-- 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).
>
>I recommend against views as they are a two-tier solution.
>
>>
>>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...