C
CMM
Short question: how to fit TableAdapters into (true) n-tier development.
More Info:
In VS2003 in terms of *physical* n-tier development, I had a fairly nice
pattern going. My DAL exists on a separate server and accessed via remoting.
In order for the client machine to "know" about the classes and methods on
the server (rather than going the lazy route and installing the server dll's
on the client) I have a very lightweight dll that contains "Types and
interfaces" that is installed on both the server and client.
This DLL acts as a WSDL file of sorts.... it contains datasets, classes, and
most importantly *interfaces* for the data access methods on the server (all
methods on the server must implement a particular Interface). This is not
hard to do and it's great because I can write a new server from the ground
up that contains the same methods but totally different implementation
without ever touching the client (at all!).
But, now in VS2005 / ADO.NET 2.0 I have a problem. I really really really
like the TableAdapter classes and the IDE designer for it. But am purplexed
that I can't PHYSICALLY separate it from the Dataset. My old pattern called
for the Datasets to exist in the "Types and Interfaces" DLL (because the
client uses them too) and the DataAdapters to exist on the remoted Server
DLL.
Anyone have any ideas on how I can adapt TableAdapters to this paradigm? I
absolutely hate the idea of putting my data access code on the client...
even if it's only going to get executed on the server. It violates the whole
notion of N-TIER development (logical layers is not the same as N-Tier...
though everyone seems to have forgotten this... including Microsoft).
P.S. I know I can continue to use DataAdapters. But, TableAdapters are way
easier to configure.
More Info:
In VS2003 in terms of *physical* n-tier development, I had a fairly nice
pattern going. My DAL exists on a separate server and accessed via remoting.
In order for the client machine to "know" about the classes and methods on
the server (rather than going the lazy route and installing the server dll's
on the client) I have a very lightweight dll that contains "Types and
interfaces" that is installed on both the server and client.
This DLL acts as a WSDL file of sorts.... it contains datasets, classes, and
most importantly *interfaces* for the data access methods on the server (all
methods on the server must implement a particular Interface). This is not
hard to do and it's great because I can write a new server from the ground
up that contains the same methods but totally different implementation
without ever touching the client (at all!).
But, now in VS2005 / ADO.NET 2.0 I have a problem. I really really really
like the TableAdapter classes and the IDE designer for it. But am purplexed
that I can't PHYSICALLY separate it from the Dataset. My old pattern called
for the Datasets to exist in the "Types and Interfaces" DLL (because the
client uses them too) and the DataAdapters to exist on the remoted Server
DLL.
Anyone have any ideas on how I can adapt TableAdapters to this paradigm? I
absolutely hate the idea of putting my data access code on the client...
even if it's only going to get executed on the server. It violates the whole
notion of N-TIER development (logical layers is not the same as N-Tier...
though everyone seems to have forgotten this... including Microsoft).
P.S. I know I can continue to use DataAdapters. But, TableAdapters are way
easier to configure.