Welcome to MSDN Blogs Sign in | Join | Help

Sushil's WebLog

Random ADO.Net discussion
Using Provider Factories

There are situation in real world; when you dont want to write code, dependent on just one of the managed provider. This also helps to easily move from using one provider to another if the code design changes in the future. Pre-Whidbey, the only way to do this was to write your own wrapper classes for the providers. In whidbey this can be done usign ProviderFactories. Here is a sample code:

using System.Data.Common;

using System.Data;

using System;

using System.Data.SqlClient;

 

namespace DataViewer.Repro

{

      public class Repro

      {

            public static int Main(string[] args)

            {

                  string conString = "ConnectionString here";

                  string cmdText = "CommandText here";

 

                  //Select SQL Client factory - Can change to use any provider later

                  DbProviderFactory factory = DbProviderFactories.GetFactory("System.Data.SqlClient");

 

                  //Create Connection from the factory

                  DbConnection cn = factory.CreateConnection();

                  cn.ConnectionString = conString;

                  cn.Open();

 

                  //Create Command from the factory

                  DbCommand cmd = factory.CreateCommand();

 

                  //Execute a command from the conneciton  

                  cmd.Connection = cn;

                  cmd.CommandText = cmdText;

                  DbDataReader reader = cmd.ExecuteReader();

                  while (reader.Read())

                  {

                        Console.WriteLine(reader.GetValue(0));

                  }

                  return 1;

            }

      }

}

After the provider is selected, there is no reference to any of the managed providers in the above code. The above code infact uses the SqlClient MP. In similar way, you can then use the factories to create Parameter, ConnectionStringBuilder, DataSourceEnumerator, Adapter, CommandBuilder and Permissions classes.

Caution:
1. Generalization might also cause an extra overhead.
2. When writing genralized code, you will not be able to use features that are provider specific. You would have to special case them.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights

Published Friday, October 08, 2004 2:24 PM by sushilc

Comments

# re: Using Provider Factories @ Friday, October 08, 2004 3:30 PM

You left out using parameters ;)

Angel

# re: Using Provider Factories @ Friday, October 08, 2004 4:07 PM

You are right Angel, in addition to parameters we can create other objects at runtime. I have edited my post.

Sushil

# re: Using Provider Factories @ Friday, October 08, 2004 10:47 PM

Welcome back Sushil - and very well done by the way.

Bill

# Kicking a33 Again! @ Saturday, October 09, 2004 1:48 AM

Bill's House O Insomnia

# Kicking a33 Again! @ Saturday, October 09, 2004 1:48 AM

Bill's House O Insomnia

# Sushil s WebLog Using Provider Factories | Paid Surveys @ Friday, May 29, 2009 1:22 PM

PingBack from http://paidsurveyshub.info/story.php?title=sushil-s-weblog-using-provider-factories

Sushil s WebLog Using Provider Factories | Paid Surveys

# Sushil s WebLog Using Provider Factories | Menopause Relief @ Tuesday, June 09, 2009 9:06 PM

PingBack from http://menopausereliefsite.info/story.php?id=1045

Sushil s WebLog Using Provider Factories | Menopause Relief

# Sushil s WebLog Using Provider Factories | internet marketing tools @ Tuesday, June 16, 2009 1:22 AM

PingBack from http://einternetmarketingtools.info/story.php?id=19787

Sushil s WebLog Using Provider Factories | internet marketing tools

Anonymous comments are disabled
Page view tracker