ADO.NET 2.0 Comings and goings

I thought I would share with you some of the significant changes that I have encountered in the course of some work that I am currently doing with ADO.NET 2.0.

Goings (as in going, going, gone !)
Already in Beta 1, the following features have been dropped:

(1) Server-side cursors & Paging
I for one, am disappointed  to see Server-side cursors (i.e. SQLResultSet) & Paging being dropped.  These were both features that were highlighted in the early presentations on ADO.NET (eg at PDC). 

Server-side cursors is a feature that developers moving to .NET immediately notice is missing.  Part of the problem, and one of the main reasons it has been dropped, is that the current model is far too easy to be misused.  The other main reason is that it is hard to scale. 

Paging (i.e. Command.ExecutePageReader) was built on top of the server-side cursor technology, so it too is gone.  This is a feature that developers (especially web developers) are always asking for. I really thought that this time MS had a very good implementation.  It wasn't perfect, but definitely very reasonable and usable.

Hopefully we'll see their return in Orcas (Longhorn version of Visual Studio).

(2) Data Components in the Toolbox
If you are used to building your data access code by starting with the Data Components on the Data Tab of the Toolbox, you may be a little distressed and concerned when you open VS Beta 1 and can't find them there.  This of course, is "By Design" J   Microsoft clearly wants to nudge us into taking advantage of the new typed DataTables and TableAdapters.  If you really, really want to insist on using the old untyped controls and components, you can manually add them back to the toolbox.  I strongly suggest that you don't…By leveraging the new partial class technology, the new typed DataSets, DataTables, and TableAdapters are much easier to use and to extend.

You can get more details from Steve Lasker's excellent post.

In the next Community Technology Preview  / Beta 2, the following features will be dropped:

(3) Transaction property of TableAdapter.  For details see Steve's other post.

(4) IXXXTableAdapter
If you create a DataTable named XXX and thenlook at the code that is generated for this class, you'll notice an odd (at least to me) implementation fact.  Rather than having the XXXTableAdapter class simply implement the defined methods (various Get, Fill, etc.) , an interface named IXXXTableAdapter is defined and then implemented by the XXXTableAdapter class.  This interface is not used anywhere else and I really couldn't see any added-value to this extra step.  Apparently Microsoft agrees and this approach and interface will be dropped.

Comings
Of course, not only are features going away, but lots of features and enhancements are coming along and being added.  Many of them are still under wraps, but let's talk about this one.

(5) Name changes for the DataConnector and the DataNavigator
Coming in the post-Beta1 builds you will see the names of the DataConnector and the DataNavigator classes changed to BindingSource and BindingNavigator respectively.  This won't be adding any functionality per se, but it will make it much clearer and easier to understand the role of these classes.  

When I first started exploring the DataConnector, it was not totally obvious what its purpose was.  I was able to pretty much figure it out, but I still thought that maybe I was missing something.  I also felt that it would be a bit difficult to explain to others what exactly it was/did.  With the upcoming name change it becomes pretty obvious what the DataConnector/BindingSource role is – to be the "binding manger" for a data source. It will also be far easier to use than the 1.1 binding context.