Tech Brief

Microsoft Sunsets .NET for Oracle: What's Next?

How to take your Oracle to .NET experience to the next level.

• By Jonathan Bruce
• 12/22/2009

Microsoft has put developers on notice that it is deprecating the ADO.NET provider for Oracle shipped with the .NET Framework: System.Data.OracleClient (OracleClient) as of .NET 4, expected in 2010. This means that Microsoft has decided to drop development of OracleClient from its ADO.NET roadmap; while the provider remains available, use of it should be avoided in new applications accessing Oracle data sources.

The company's decision has broad implications and has generated dismay in some quarters of the developer community, who see it as a short-sighted move motivated by economic expediency. However, it is also a powerful endorsement for some of the third-party ADO.NET providers available. Microsoft’s ADO.NET OracleClient former program manager Himanshu Vasishth stated in the ADO.NET Team blog in June: "Many third-party providers are able to consistently provide the same level of quality and support that customers have come to expect from Microsoft."

There has been much speculation regarding the impact of Microsoft’s decision on use of the ADO.NET Entity Framework — the most significant development for a data access programming paradigm within the .NET Framework. Those considering Oracle providers in planning to move their Oracle-based infrastructure to the ADO.NET Entity Framework no longer have a Microsoft option that promises viability into the future.

Version 1 of Entity Framework had notable shortcomings that have been addressed in the upcoming version (called Entity Framework v4 because it forms part of .NET 4), available in Beta as part of Visual Studio 2010. Two key highlights will make Entity Framework more usable: Foreign Key support and Code First. The first translates directly into the ensure data integrity enforcement, right up to the data model. Code First — a glaring omission for Entity Framework in light of its main competitor, NHibernate — allows developers to design truly independent data models and delegate persistence ignorance to the underlying data store.

Another good approach to data access is the use of Data Access Application Blocks (DAAB). Components of Microsoft’s Enterprise Libraries, DAAB allows IT organizations to migrate from an approach where each application contains its own data access logic to one where each application accesses a separate but common data access layer. As with Entity Framework, a robust vendor community offering data connectivity providers for DAAB allows developers to package the data access strategy for applications that must reside close to the database. DAABs are best considered complementary to an Entity Framework approach.

The barometer of success for the ADO.NET Entity Framework as a technology is gauged solely by the diversity of supporting data providers (drivers) and data sources. One has only to look at the success of Microsoft’s Language Integrated Query (LINQ) and its diverse ecosystem of supporting data sources as an example.

In the absence of viable Microsoft-supplied providers going forward, the right choice of third-party provider can take Oracle-based customers well beyond what they came to expect from Microsoft’s ADO.NET providers. ADO.NET 1.0 was initially conceived to provide access to SQL Server and was retrofitted as part of the .NET Framework to accommodate heterogeneous databases. It can really be an odd fit with Oracle in certain cases. A good third-party vendor subjects its ADO.NET providers to extensive testing against their given target databases.

Migrating existing applications away from using Microsoft’s deprecated OracleClient is, for plain vanilla ADO.NET methods and fields of all types, a relatively mundane task. Migrating to generic data types — as with a DAAB — is more involved, yet still purely procedural, with refactoring the required references the final step before re-compilation. Entity Framework greatly simplifies the process: migrate the SSDL entries in the EDMX file to reference the specific data types for a third-party provider supporting Entity Framework Oracle, and change up the application configuration settings tools.

Is a commercial third-party provider the only option available? Not exactly. The Oracle database includes an ADO.NET provider — Oracle Data Provider for .NET or ODP.NET — that can be used. However, this "free" option can actually involve considerable expense, and has drawbacks that cannot be ignored.

A primary drawback is actually one shared with OracleClient: it is not 100 percent managed. Both OracleClient and ODP.NET, as well as the new Oracle Instant client, make calls to unmanaged code in the form of client libraries, slowing performance and compromising the .NET Framework’s services involving security and memory management. Deployment headaches also come with having to deploy client software on hundreds or possibly thousands of machines.

ODP.NET also introduces the challenge of versioning; it calls the unmanaged Oracle client pieces specific to a particular version of the Oracle database, so that running two versions with the data provider — for example, Oracle 9i and Oracle 10g — on the same machine results in conflict. This problem is typically addressed by deploying multiple mid-tier servers, each running different database client software, making for a more costly, convoluted, and difficult-to-manage environment.

In the case of nearly every project involving data connectivity, a myopic focus on solving the immediate challenge at hand is a non-strategy that can cause trouble and expense down the road. For applications in data environments with any sort of complexity or heterogeneity, third-party ADO.NET providers are worth considering.

The good news is that implementing this approach gives you the opportunity to reap the full benefits of the .NET Framework via a 100 percent managed data access solution. Third-party data providers can boost data access performance, and lay the groundwork for more efficient development. With sufficient planning, the return on investment will compensate for the added cost of using a third-party ADO.NET provider.