More Perplexed by .NET 2.0

I spent most of the evening pondering a problem that I heard about from Jesse Liberty (author of a number of O'Reilly .NET books).  Admittedly, I haven't spent as much time with ASP.NET 2.0 as I would have liked, so I got down to writing a website with the SqlDataProvider object.  Wow, it hides everything.  While this will get the small site up and running very fast, I am afraid it will point people are creating lots of single resultset queries.  Back to ADO land. 
 
Ok, but what if you want to use a DataSet to hold hierarchical data?  Well, the DataSet and DataAdapters not only are not on the Data Palette (like they should be), but for some reason you can't even add them manually.  The only way I could get this to work was to create a DataSet in a separate project (yes, a separate project) and reference that project from the Web Project.  Even so, I was still left with creating a Typed DataSet and a Component for the Adapters like I do in 1.x.  If they are going to add the idea of a TableAdapter to the Typed DataSet (good idea guys), we also need allow DataAdapters to be added to the Typed DataSet.  Why?  Because retrieving your data one table at a time is a bad practice.  Again, DataAdapters do a good job of retrieving batch resultsets and mapping them to an entire Typed DataSet object. 
 
I know there was a lot of blowback about the traditional single resultset bunch who were used to working a certain way.  Allow the case where a single resultset is needed is a great step forward, but don't erase the larger case to meet that demand.  Please...
 
Maybe the strategy continues to be, "Don't use Typed DataSets...go back and create Data Libraries of Objects".  Please don't give us tools and then take them away when we're finally getting good at them. 
 
Hmph!

Comments:

So what does this mean for those of us with a substantial investment in ADO.NET 1.1 (or maybe it should be ADO.NET Classic)?

I've got strongly typed datasets for hierarchical data. In general, a dataset is not just one table for me, but multiple tables, so that I can let ADO.NET help me manage the relationships.

Will this stuff still compile on .NET 2.0, or am I looking at a substantial rewrite of my data abstraction layer?

The main thing I need is the ability to allow strongly typed datasets to use "generic" strongly typed tables that I can use across pages. This is because the strongly typed tables are often used to populate a user control, and the user control cannot take advantage of the strongly typed table or row if the type name varies for every page.

This seems like a very obvious improvement to me, a person who appreciates the advantages of a single database call per page.

Is this possible in 2.0?

Maestrocity, I don't quite understand what you mean. Feel free to comment with another explanation (or send me e-mail) because I might really like what you're talking about.

Sure, I can try to explain more. Normally when I create a single strongly typed dataset for an entire page I will use an XSD include file that contains attribute-groups relating to tables needed by user controls that are utilized on more than one page. The problem with this is that say I have 2 pages, one PageA and the other PageB. Both have strongly-typed tables defined in an XSD dataset definition that utilize the same XSD include file. Both are named UserControlTable. Now when I create a public property of the user-control that is used to "bind" the control to data, I must specify a generic datarow for the binding, since one strongly typed row will be name PageA.UserControlTableRow and the other PageB.UserControlTableRow. Since I use lots of user-controls, the advantage of the strongly typed dataset is largely nullified for me. So what I would like is to build an auto-generated strongly typed dataset up from multiple, already-existing strongly typed tables. Then I could associate the strongly-typed tables directly with the user-control.

I hope this explains...


 



 
Save Cancel