Microsoft’s Recent ADO.NET Survey

The ADO.NET Team at Microsoft recently published the results of a survey to get feedback on what members of the .NET community would like to see in upcoming releases. It's great to see Microsoft actively soliciting feedback from the .NET community but it's another thing entirely to actually release product updates that contain the features requested. As with any product road map or projections it is only fair to assume that these features could, and likely will change.

While standards and data connectivity have long gone hand in hand, we have stuck close to somewhat contrary principle of "innovation beyond the specification". Instead of simply waiting for the .NET platform or ADO.NET specification to provide support for critical features important to enterprise .NET applications, our Connect for ADO.NET providers deliver many of these features today in a 100% spec-compliant way. Looking down the wish list published by ADO.NET team, we thought we'd share some several items that .NET developers and architects don't have to wait for, as well as some of the ideas we think are a great addition to vanilla ADO.NET.

Improve command batching by introducing a way to group parameterized DbCommands in order and send them to the server in just one operation.

Batching is one the most effective techniques available today to save on costly network I/O. JDBC and ODBC APIs have had this for many years, and it's something Connect for ADO.NET has enjoyed for quite some time. Simply trigger the BatchUpdateBehavior option you can trigger the ability to group together a series of comments, and to inject just that additional piece of magic you can even do array binding too.

Uniform schema discovery API across all managed providers.

While this type of API would be useful, a better solution would be a uniform organization and approach that's supported across any database. Progress DataDirect Connect for ADO.NET allows users to get schema from different databases using the same approach across the board – plus we can leverage some of the lessons we've learnt in supporting formal schema discovery mechanism as defined by standards like ODBC and JDBC.

Uniform bulk copy API across all managed providers and improved overall experience.

Boom! This is probably our favorite. We find ourselves dealing heterogeneous data access challenges and as a result can point to things we've done with our .NET product to make it as easy and uniform as possible irrespective of whether you use the ever popular Data Access Application Block from Microsoft P&P or even the ADO.NET Entity Framework. This approach is extended to our support for bulk operations in ADO.NET where today any developer can use common DbCommand syntax to issue a bulk copy into a destination database using our Oracle, SQL Server, Sybase, or DB2 providers.

Set credentials outside of the connection string.

The core issue here is the current requirement for users to transmit confidential information inside the connection string. Rather than placing credentials in a plain text connection string, developers instead can use a pop-up dialog box for User IDs and Passwords, which will encrypt the data automatically, depending on which database you're sending it to. This is a great proposal from Microsoft, especially given how so many of the .NET patterns enforce connection pool utilization, there are some interesting optimizations here.

Improve the granularity of how the connection string is used to map logical-to-physical connections in the Connection Pool (CP).

This issue is all about giving the developer flexibility in how they want to reuse connections because you don't always want the same connection pooling behavior for every application. Our Connect for ADO.NET providers give developers 4 options for tuning pooled connections for on different use cases. And because these options are enabled on the connection string, developers can tune them without having to change their application code.

Specify Kerberos Authentication in the connection string.

Our Connect for ADO.NET providers offer support for Kerberos-based authentication for Oracle, Sybase, DB2, and SQL Server as well as the ability to specify in connection string if you want Kerberos, standard Username and Password authentication or NTLM.

As always, I the proof is in the pudding. Go grab a copy of Connect for ADO.NET today and see the difference for yourselves!