TableAdapters and true N-Tier

  • Thread starter Thread starter CMM
  • Start date Start date
C

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.
 
Well i can only say one thing regarding this

I agree ...

regards

Michel Posseth [MCP]
 
CMM said:
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.
Click to expand...

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
 
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.
Click to expand...

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.
Click to expand...

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.
 
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.
__________________________________
 
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

Sahil Malik said:
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
Click to expand...
 
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
William (Bill) Vaughn said:
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.
__________________________________
Click to expand...
 
For what, the next major release of VS or what??? This should have been done
right in VS2005 to begin with.
Click to expand...

So you believe the inventor of the steam engine should have invented the modern
gasoline engine instead, because they would have been better?

Seriously though, I believe the answer I saw in the link you provided explained
why they didn't do what you suggested. Maybe they should have done what you
suggested, but they probably had 10,000 other good ideas to implement also.

As a developer, I'm sure you have been told to leave something out because the
marketing group or management didn't want to wait for the extended release date
required to deliver the latest whiz bang improvement.
Good luck with your project,

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com
 
I would hardly compare TableAdapters to the Steam Engine. You wouldn't be
either if you were coding longer than 3 years. They're more like a
RE-invention of the Steam Engine... These sort of half-cooked not
thought-through "innovations" from Microsoft may have been acceptable (even
revolutionary) back in 1995-1999... but not today.

To this day, I have to jump through hoops to make a 6 year old huge
2-tiered, network chatty, in-house CRM-esque application slightly bearable
over VPN by paying bucketloads for more ISP bandwidth, dedicated lines, many
switches, etc. etc). TableAdapters will ensure that many of us will be doing
similar things with many .NET apps (built by dolts who don't know the
different between tiers and layers) for years to come. Thanks Microsoft.
 
I would hardly compare TableAdapters to the Steam Engine. You wouldn't be
either if you were coding longer than 3 years. They're more like a
RE-invention of the Steam Engine... These sort of half-cooked not
thought-through "innovations" from Microsoft may have been acceptable (even
revolutionary) back in 1995-1999... but not today.

To this day, I have to jump through hoops to make a 6 year old huge
2-tiered, network chatty, in-house CRM-esque application slightly bearable
over VPN by paying bucketloads for more ISP bandwidth, dedicated lines, many
switches, etc. etc). TableAdapters will ensure that many of us will be doing
similar things with many .NET apps (built by dolts who don't know the
different between tiers and layers) for years to come. Thanks Microsoft.
Click to expand...

Actually, I've been coding for thirty years, young fella...

Good luck with your project,

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com
 
Back
Top