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.