TableAdapters and true N-Tier

[CMM]

Unless someone has come up with a way, I still don't understand how you can
use TableAdapters in a true n-tier infrastructure.... where the
DataAccessLayer is in one Dll and *only* the Datasets themselves can be
shared across layers.

I find it inconceivable that this suggestion
http://lab.msdn.microsoft.com/produ...edbackid=d2907b53-885b-4d24-bc9c-1a04d76036e4
(that's not me who suggested it) has been marked as "won't fix."
.... even more strange that there hasn't been more of clamor about this in
the community. It seems that everybody nowadays either wasn't programming a
few years ago in VB.Classic days or has gotten amnesia and forgotten the
lessons learned in the past.

The TableAdapters are more robust than a regular DataAdapter. BUT, they're
USELESS if you can't place them outside of the DataSet *FILE* or dll as a
whole. I mean, they're placed in a separate namespace, they're not
intrinsically tied to the DataSet (i.e. they're not a nested class), and
placing them in the Dataset files violates TRUE n-tier rules.

 

[Michel Posseth [MCP]]

Well i can only say one thing regarding this

I agree ...

regards

Michel Posseth [MCP]

 

[Sahil Malik [MVP C#]]

I don't like TableAdapters.

Forget n-tier, they have other problems too.

Here are my views on 'em -
http://groups.google.com/group/microsoft.public.dotnet.framework.adonet/msg/d9fb36b0b3192bc3?hl=en&


- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx

 

[David Browne]

Unless someone has come up with a way, I still don't understand how you
can use TableAdapters in a true n-tier infrastructure.... where the
DataAccessLayer is in one Dll and *only* the Datasets themselves can be
shared across layers.

I find it inconceivable that this suggestion
http://lab.msdn.microsoft.com/produ...edbackid=d2907b53-885b-4d24-bc9c-1a04d76036e4
(that's not me who suggested it) has been marked as "won't fix."
... even more strange that there hasn't been more of clamor about this in
the community. It seems that everybody nowadays either wasn't programming
a few years ago in VB.Classic days or has gotten amnesia and forgotten the
lessons learned in the past.

The TableAdapters are more robust than a regular DataAdapter. BUT, they're
USELESS if you can't place them outside of the DataSet *FILE* or dll as a
whole. I mean, they're placed in a separate namespace, they're not
intrinsically tied to the DataSet (i.e. they're not a nested class), and
placing them in the Dataset files violates TRUE n-tier rules.

Why not just set the Table Adapters to "internal"? The DataAccessLayer
would be in one DLL and only the Datasets themselves would be shared.

Or why not go one better and not share the DataSet definitions at all.
Create an interface for each entity, and make the DataSet entities
(DataTables and DataRows) implement those interfaces. Then client code can
bind to the interfaces, and never have to know that it's reading and writing
to DataSets.


David

 

[CMM]

Or why not go one better and not share the DataSet definitions at all.

Create an interface for each entity, and make the DataSet entities
(DataTables and DataRows) implement those interfaces. Then client code
can bind to the interfaces, and never have to know that it's reading and
writing to DataSets.

This is interesting... as I use interfaces already in a shared dll to
communicate with the DAL (i.e. the DAL dll doesn't get installed on the
client machine just to provide class definitions a la the lazy-man's
n-tier). But DataSets (and other "data-only" types and classes) get put into
the same shareable "Types" dll. I'll have to look into it.... seems like an
aweful lot of work though to extend the "Interfaces" paradigm to Datasets as
well.

Why not just set the Table Adapters to "internal"? The DataAccessLayer
would be in one DLL and only the Datasets themselves would be shared.

I didn't know you could do that. You're saying you can *hide* the
TableAdapters? I'll look into it. But it still feels a bit icky.

 

[William \(Bill\) Vaughn]

I expect that the MS folks are working on this aspect of TableAdapters.
Check out Jackie Goldstein's comments as well. He's been demonstrating how
to do this in his talks.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

 

[CMM]

I've said it many times.... the CLR (and for the most part Framework too)
guys did an outstanding job on .NET 2.0. But the IDE and Editor/Designer
guys were asleep the whole time. It's like everything was written by a bunch
of amatuers straight out of college.

Wow... I just read your article. I didn't know about the queries .... but
now I see in the code behind the bunch of "& _ " used to build the queries.
Ridiculous. Just plain ridiculous.

--
-C. Moya
www.cmoya.com

I don't like TableAdapters.

Forget n-tier, they have other problems too.

Here are my views on 'em -
http://groups.google.com/group/microsoft.public.dotnet.framework.adonet/msg/d9fb36b0b3192bc3?hl=en&


- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx

 

[CMM]

For what, the next major release of VS or what??? This should have been done
right in VS2005 to begin with.

--
-C. Moya
www.cmoya.com

I expect that the MS folks are working on this aspect of TableAdapters.
Check out Jackie Goldstein's comments as well. He's been demonstrating how
to do this in his talks.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no
rights.
__________________________________