ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Сначала укажите ссылку на компоновочный блок System.Configuration.dll, добавьте в текущий проект файл арр.config и определите элемент ‹appSettings›. Помните о том, что "официальным" форматом значения поставщика является полное имя пространства имен поставщика данных, а не такое фиктивное имя, как то, которое использовалось выше в примере MyConnectionFactory.

‹configuration›
 ‹appSettings›
 ‹!-- Какой поставщик?– -›
 ‹add key="provider'' value="System.Data.SqlClient" /›
‹!-- Какая строка соединения? – -›
 ‹add key="cnStr" value="Data Source=localhost;uid=sa;pwd=;Initial Catalog=Pubs"/›
 ‹/appSettings›
‹/configuration›

Теперь, когда у вас есть соответствующий файл *.config, вы можете прочитать из него значения provider и cnStr, используя метод ConfigurationManager.AppSettings. Значение provider будет передано методу DbProviderFactories.GetFactory, чтобы получить специфичный для данного поставщика тип источника данных. Значение cnStr будет использоваться для установки свойства ConnectionString типа DbConnection. В предположении о том, что вы: указали using для пространств имен System.Data и System.Data.Common, обновите метод Main так, как показано ниже.

static void Main(string[] args) {
 Console.WriteLine("*** Источники поставщиков данных ***\n");
 // Получение строк соединения и поставщика данных из файла *.config.
 string dp = ConfigurationManager.AppSettings("provider");
 string cnStr = ConfigurationManager.AppSettings("cnStr");
 // Создание источника поставщика.
 DbProviderFactory df = DbProviderFactories.GetFactory(dp);
 // Создание объекта соединения.
 DbConnection cn = df.CreateConnection;
 Console.WriteLine("Объект соединения: {0}", cn.GetType.FullName);
 cn.ConnectionString = cnStr;
 cn.Open;
 // Coздание объекта команды.
 DbCommand cmd = df.CreateCommand;
 Console.WriteLine("Объект команды: {0}", cmd.GetType.FullName);
 cmd.Connection = cn;
 cmd.CommandText = "Select * From Authors";
 // Вывод данных с помощью объекта чтения данных.
 DbDataReader dr = cmd.ExecuteReader(CommandBehavior.CloseConnection);
 Console.WriteLine("Объект чтения данных: {0}", dr.GetType.FullName);
 Console.WriteLine("\n***** Авторы в Pubs *****");
 while(dr.Read) Console.WriteLine("-› {0}, {1}", dr["au_lname"], dr["au_fname"]);
 dr.Close;
}

Здесь для проверки печатаются полные имена объекта соединения, объекта команды и объекта чтения данных. Запустив это приложение, вы обнаружите, что для чтения данных из таблицы Authors базы данных Pubs был использован поставщик Microsoft SQL Server (рис. 22.2).

Рис. 22.2. Получение поставщика данных SQL Server с помощью источника поставщика данных .NET 2.0

Далее, если вы измените файл *.config так, чтобы в нем для поставщика данных было указано System.Data.OleDb (и соответственно обновите строку соединения), как предлагается ниже:

‹configuration›
 ‹appSettings›
 ‹!-- Which provider?– -›
 ‹add key="provider" value="System.Data.OleDb"/›
 ‹!-- Which connection string?– -›
 ‹add key="cnStr" value="Provider=SQLOLEDB;Data Source=localhost;uid=sa;pwd=;Initial Catalog=Pubs" /›
 ‹/appSettings›
‹/configuration›

то вы обнаружите, что теперь в фоновом режиме используются типы System.Data. OleDb (рис. 22.3).

Рис. 22.3. Получение поставщика данных OLE DB с помощью источника поставщика данных .NET 2.0

Конечно, не имея опыта работы с ADO.NET, вы можете иметь слабое представление о том, что именно делают объекты соединения, команды и чтения данных. Но не беспокойтесь до поры до времени о деталях (в конце концов, в этой главе еще немало страниц, а вам только предстоит их прочесть!). На данный момент важно только понять, что в .NET 2.0 вполне возможно построить единый базовый код, который сможет в декларативной форме принимать разных поставщиков данных.

Предложенная модель оказывается очень мощной, но вы должны убедиться в том, что ваш базовый программный код использует только те типы и методы, которые оказываются общими для всех поставщиков. Поэтому при создании общего программного кода ограничьте себя использованием членов, предлагаемых DbConnection.DbCommand и другими типами из пространства имен System.Data. Common. С другой стороны, вполне возможно, что такой "обобщённый" подход не позволит использовать некоторые специфические возможности конкретной СУБД, так что обязательно проверьте работоспособность создаваемого вами программного кода в реальных условиях.

Элемент ‹connectionStrings›

В рамках .NET 2.0 файлы конфигурации приложения могут определить новый элемент, названный ‹connectionStrings›. В контексте этого элемента вы можете определять любое число пар имен и значений, которые можно будет прочитать программными средствами, используя индексатор ConfigurationManager.ConnectionStrings. Главным преимуществом этого подхода (в отличие от использования элемента ‹appSettings› и индексатора ConfigurationManager.AppSettings) является то, что в этом случае вы можете определять множество строк соединений для одного приложении в единообразном стиле.

Для примера обновите свой файл арр.config так, как показано ниже (заметьте, что каждая строка соединения здесь задается атрибутами name и connection-String, a не key и value, как в случае ‹appSettings›).

‹configuration›
 ‹appSettings›
 ‹!-- Which provider?– -›
 ‹add key= "provider" value="System.Data.SqlClient" /›
 ‹/appSettings›
 ‹connectionStrings›