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 1044
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: Brett Romero |
last post by:
I store my server and database names in a static class that all
libraries use. Using a config file, I can switch from test, staging,
or production servers easily.
I like what TableAdapters are...
|
by: DG |
last post by:
How to update TableAdapters using tranasactions?
is this a good sample?
http://www.mybug.bloger.hr/post/tableadapters-and-transactions/179426.aspx
|
by: Max2006 |
last post by:
Hi,
I saw the Business Logic Layer pattern suggested at the following link and I
found that the pattern never closes the connection:
...
|
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: SAL |
last post by:
Hello,
I would like to be able to set the WHERE clause of a select statement on the
fly. I have a DataAccess layer designed using the DataSet designer and a
BusinessLogic layer using classes. The...
|
by: tiger00555 |
last post by:
in reference to the below thread:
http://bytes.com/groups/net-asp/344508-tableadapters-web-config
does this issue still exist in visual studio 2008? I guess having a build environment with...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
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...
| |