Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFPConversion Seminar - May 9-10 - Dallas, TX
Message
From
19/04/2005 03:05:11
Walter Meester
HoogkarspelNetherlands
 
 
To
19/04/2005 00:49:20
General information
Forum:
Visual FoxPro
Category:
Conferences & events
Miscellaneous
Thread ID:
01002513
Message ID:
01006075
Views:
43
Hi Bonnie,

>No, when I say DataAccess layer (tier, whatever), I'm not talking about SPs on the SQL Server. I'm talking about code ... middle tier kind of stuff. So, when I was talking about the fact that using SPs does not make the application database dependent, what I meant was this. Your middle tier Biz class calls a middle tier DataAccess class. It's the DataAccess class that knows which kind of database it's talking to (SqlServer, Oracle, whatever). You may have different SPs on each of those different kinds of database servers, but bottom line is that you return the same kind of data. The DataAccess class sends the same DataSet back to the Biz class, no matter which database server is being accessed.

I'm sure you know this, but for the lurkers: There is a difference between the definition of tiers and layers. One executable can consist out of many layers. Layers are logical separation of levels of implementation. Each layer communicates with an upper or lower level through a defined interface. Tiers on the other hand are simiular to layers, but they generally run in different processes and even on other machines.

Exchanging a tier is easy, exchanging a layer within a might requires a recompile.

>>Instead the data access layer IMO, belongs on a middletier using SPT (Sql pass through) or RVs (VFP), ADO.NET typed datasets (.NET) (and yes, I think it is fair to compare them to a large extent thoug there obviously are some differences)<
>
>I think we basically agree on that.
>
>But, we still need to clear something up. You said:
>
>>It seems that in .NET I'll have to deal with two different dataacess methodologies, typed and untyped datasets.<
>
>And after I disagreed with that by saying this:
>
>>DataSets have nothing to do with DataAccess. They are simply a way of representing data. DataSets are totally "disconnected" from the back-end data.<
>
>You countered with this:
>
>>My statement was accross the line, that you have essential two techniques to get at your data stored in datasets: Typed and Untyped access, just as you described in a prior message.<
>
>OK, so I guess what you're saying is that once you get the data from the database into a DataSet, then you have a choice of using that data as a Typed DataSet or un-typed DataSet? If that's what you're saying, then yeah, you have that choice. My point is that after using Typed DataSets, I can't imagine why anyone would want to use un-typed DataSets ... they Typed ones are definitely preferable, IMHO.

Yep, that is what I meant. As to your statment that you "can't imagine why anyone would want to se un-typed DataSets", I can say that in a few of my products there is a query designer present in which the user can define their own queries. In this case the SQL statment is build up during runtime. In this case you don't have any other choice than using SPT and can't use typed datasets at all. You'll have to workarround the limitations implied by that, by dealing with untyped access. But I agree typed dataaccess seems to be preferable IMO where applicable.

Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform