Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > TableAdapters and true N-Tier

Reply
Thread Tools

TableAdapters and true N-Tier

 
 
CMM
Guest
Posts: n/a
 
      04-21-2006
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/produc...c-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.

--
-C. Moya
www.cmoya.com


 
Reply With Quote
 
 
 
 
Michel Posseth [MCP]
Guest
Posts: n/a
 
      04-21-2006
Well i can only say one thing regarding this

I agree ...

regards

Michel Posseth [MCP]



"CMM" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> 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/produc...c-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.
>
> --
> -C. Moya
> www.cmoya.com
>



 
Reply With Quote
 
 
 
 
Sahil Malik [MVP C#]
Guest
Posts: n/a
 
      04-21-2006
I don't like TableAdapters.

Forget n-tier, they have other problems too.

Here are my views on 'em -
http://groups.google.com/group/micro...3192bc3?hl=en&


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


"CMM" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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/produc...c-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.
>
> --
> -C. Moya
> www.cmoya.com
>



 
Reply With Quote
 
David Browne
Guest
Posts: n/a
 
      04-21-2006

"CMM" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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/produc...c-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


 
Reply With Quote
 
CMM
Guest
Posts: n/a
 
      04-21-2006
> 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.

--
-C. Moya
www.cmoya.com
"David Browne" <davidbaxterbrowne no potted http://www.velocityreviews.com/forums/(E-Mail Removed)> wrote in
message news:%(E-Mail Removed)...
>
> "CMM" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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/produc...c-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
>



 
Reply With Quote
 
William \(Bill\) Vaughn
Guest
Posts: n/a
 
      04-21-2006
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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/produc...c-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.
>
> --
> -C. Moya
> www.cmoya.com
>



 
Reply With Quote
 
CMM
Guest
Posts: n/a
 
      04-21-2006
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 [MVP C#]" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>I don't like TableAdapters.
>
> Forget n-tier, they have other problems too.
>
> Here are my views on 'em -
> http://groups.google.com/group/micro...3192bc3?hl=en&
>
>
> - Sahil Malik [MVP]
> ADO.NET 2.0 book -
> http://codebetter.com/blogs/sahil.ma.../13/63199.aspx
> ----------------------------------------------------------------------------
>
>
> "CMM" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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/produc...c-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.
>>
>> --
>> -C. Moya
>> www.cmoya.com
>>

>
>



 
Reply With Quote
 
CMM
Guest
Posts: n/a
 
      04-21-2006
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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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/produc...c-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.
>>
>> --
>> -C. Moya
>> www.cmoya.com
>>

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[False,True] and [True,True] --> [True, True]????? bdb112 Python 45 04-29-2009 02:35 AM
Visual Studio 2008 TableAdapters and Transactions Andrew Jocelyn ASP .Net 3 04-03-2008 04:07 AM
ASP.Net website structure - TableAdapters and a Class Library =?Utf-8?B?TWFydHluIEZld3RyZWxs?= ASP .Net 3 09-13-2006 01:37 PM
tableadapters and database default values neilmcguigan@gmail.com ASP .Net 0 06-14-2006 09:47 PM
TableAdapters and web.config =?Utf-8?B?Q2hyaXN0b3BoZXIgS2ltYmVsbA==?= ASP .Net 3 10-12-2005 01:16 AM



Advertisments