Writing Provider-Independent Data Access Code with ADO.NET 2.0
When you need to write an application that allows users to select the database provider, the application code itself needs to be completely provider-independent. ADO.NET 2.0 helps you create and deliver database applications even when you don't know what database your clients are using.
by Alex Homer
February 17, 2005
he data access features in .NET changed the way developers write code by segregating the data providers into separate classes and namespaces, depending on the type of database that was being targeted. For example, to access SQL Server, Microsoft encourages you to use the classes from the System.Data.SqlClient namespace, such as SqlConnection and SqlDataReader, which take advantage of the better performance available through SQL Server's native Tabular Data Stream (TDS) interfaces.
However, if you do that, your code won't work if you switch to a different database system, and you may need to change your code to use classes in the OleDb or Odbc namespaces instead. Of course, you can do a global search and replace to rewrite the code, but that's of no value if you want to be able to select the provider type through a simple configuration setting, or even dynamically at runtime.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
he data access features in .NET changed the way developers write code by segregating the data providers into separate classes and namespaces, depending on the type of database that was being targeted. For example, to access SQL Server, Microsoft encourages you to use the classes from the System.Data.SqlClient namespace, such as SqlConnection and SqlDataReader, which take advantage of the better performance available through SQL Server's native Tabular Data Stream (TDS) interfaces.
