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 7 930
Well i can only say one thing regarding this
I agree ...
regards
Michel Posseth [MCP]
"CMM" <cm*@nospam.com> schreef in bericht
news:O5**************@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/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
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" <cm*@nospam.com> wrote in message
news:O5**************@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/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
"CMM" <cm*@nospam.com> wrote in message
news:O5**************@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/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
> 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 me**@hotmail.com> wrote in
message news:%2****************@TK2MSFTNGP04.phx.gbl... "CMM" <cm*@nospam.com> wrote in message news:O5**************@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/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
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" <cm*@nospam.com> wrote in message
news:O5**************@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/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
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#]" <co*****************@nospam.com> wrote in message
news:%2****************@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/micro...3192bc3?hl=en&
- Sahil Malik [MVP] ADO.NET 2.0 book - http://codebetter.com/blogs/sahil.ma.../13/63199.aspx ----------------------------------------------------------------------------
"CMM" <cm*@nospam.com> wrote in message news:O5**************@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/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
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" <bi**************@nwlink.com> wrote in message
news:u5**************@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" <cm*@nospam.com> wrote in message news:O5**************@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/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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Christopher Kimbell |
last post by:
I have a class library that contains a number of TableAdapters and I'm using
this from a web application. Is there a way of getting the TableAdapters to
use the connectionstrings defined in...
|
by: spooke |
last post by:
HI all
now are two days, 20 hours of work that i'm on this problem without a
solution!!!
I think i'll become mad!!!
Here is the problem:
I Use C# 2.0 (VS .Net 2005) with thyped dataset
I...
|
by: rswafford |
last post by:
Hi, I am beginning to rewrite an application in ASP.NET 2.0, and I want
to utilize strongly typed TableAdapters for my data access layer.
However the database that gets queried is not known until...
|
by: Ted Ngo |
last post by:
I create a northwind Strongly Typed TableAdapters dataset,
the create a query like "select a, b, c, d from employeetable"
then bind it into the gridview
dim t as new northwindTableAdapters...
|
by: =?Utf-8?B?R3JlZw==?= |
last post by:
When using the VS Wizards to create a DataSet I select tables. Then, I use
the TableAdapter Configuration Wizard to modify the underlying queries that
retreive the data. What I'm wonder is, does...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |