|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
TableAdapters and true N-Tieruse 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/productfeedback/viewfeedback.aspx?feedbackid=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] Show quote "CMM" <cmm@nospam.com> schreef in bericht news:O5ZD6mVZGHA.1348@TK2MSFTNGP05.phx.gbl... > 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/productfeedback/viewfeedback.aspx?feedbackid=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. > > -- > -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 ---------------------------------------------------------------------------- Show quote "CMM" <cmm@nospam.com> wrote in message news:O5ZD6mVZGHA.1348@TK2MSFTNGP05.phx.gbl... > 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/productfeedback/viewfeedback.aspx?feedbackid=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. > > -- > -C. Moya > www.cmoya.com > 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. Show quote "Sahil Malik [MVP C#]" <contactmethrumyblog@nospam.com> wrote in message news:%23XQSWQWZGHA.3524@TK2MSFTNGP04.phx.gbl... >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" <cmm@nospam.com> wrote in message > news:O5ZD6mVZGHA.1348@TK2MSFTNGP05.phx.gbl... >> 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/productfeedback/viewfeedback.aspx?feedbackid=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. >> >> -- >> -C. Moya >> www.cmoya.com >> > >
Show quote
"CMM" <cmm@nospam.com> wrote in message Why not just set the Table Adapters to "internal"? The DataAccessLayer news:O5ZD6mVZGHA.1348@TK2MSFTNGP05.phx.gbl... > 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/productfeedback/viewfeedback.aspx?feedbackid=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. > 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. This is interesting... as I use interfaces already in a shared dll to > 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. 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 I didn't know you could do that. You're saying you can *hide* the > would be in one DLL and only the Datasets themselves would be shared. TableAdapters? I'll look into it. But it still feels a bit icky. Show quote "David Browne" <davidbaxterbrowne no potted m***@hotmail.com> wrote in message news:%23LoOUTWZGHA.3448@TK2MSFTNGP04.phx.gbl... > > "CMM" <cmm@nospam.com> wrote in message > news:O5ZD6mVZGHA.1348@TK2MSFTNGP05.phx.gbl... >> 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/productfeedback/viewfeedback.aspx?feedbackid=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 > 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. -- Show quote____________________________________ 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" <cmm@nospam.com> wrote in message news:O5ZD6mVZGHA.1348@TK2MSFTNGP05.phx.gbl... > 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/productfeedback/viewfeedback.aspx?feedbackid=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. > > -- > -C. Moya > www.cmoya.com > For what, the next major release of VS or what??? This should have been done
right in VS2005 to begin with. Show quote "William (Bill) Vaughn" <billvaRemoveT***@nwlink.com> wrote in message news:u5F35hWZGHA.1204@TK2MSFTNGP04.phx.gbl... >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" <cmm@nospam.com> wrote in message > news:O5ZD6mVZGHA.1348@TK2MSFTNGP05.phx.gbl... >> 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/productfeedback/viewfeedback.aspx?feedbackid=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. >> >> -- >> -C. Moya >> www.cmoya.com >> > > On Fri, 21 Apr 2006 13:33:05 -0400, "CMM" <cmm@nospam.com> wrote: So you believe the inventor of the steam engine should have invented the modern>For what, the next major release of VS or what??? This should have been done >right in VS2005 to begin with. 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. Show quote "Otis Mukinfus" <ph***@emailaddress.com> wrote in message news:golk425hvgpmrbl47tk43kj1vb8irg8ls1@4ax.com... > On Fri, 21 Apr 2006 13:33:05 -0400, "CMM" <cmm@nospam.com> wrote: > >>For what, the next major release of VS or what??? This should have been >>done >>right in VS2005 to begin with. > > 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
Show quote
On Mon, 24 Apr 2006 17:40:45 -0400, "CMM" <cmm@nospam.com> wrote: Actually, I've been coding for thirty years, young fella...>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. Good luck with your project, Otis Mukinfus http://www.arltex.com http://www.tomchilders.com  |
|||||||||||||||||||||||
Other interesting topics