Следующий пример кода позволяет выбирать специфический объект подключения на основе значения из специального перечисления. В целях диагностики мы просто выводим лежащий в основе объект подключения с применением служб рефлексии.

using System;

using System.Data;

using System.Data.Odbc;

#if PC

  using System.Data.OleDb;

#endif

using Microsoft.Data.SqlClient;

using MyConnectionFactory;

Console.WriteLine("**** Very Simple Connection Factory *****\n");

Setup(DataProviderEnum.SqlServer);

#if PC

  Setup(DataProviderEnum.OleDb); // He поддерживается в macOS

#endif

Setup(DataProviderEnum.Odbc);

Setup(DataProviderEnum.None);

Console.ReadLine;

void Setup(DataProviderEnum provider)

{

  // Получить конкретное подключение.

  IDbConnection myConnection = GetConnection(provider);

   Console.WriteLine($"Your connection is a {myConnection?.GetType.Name ?? 

"unrecognized type"}");

  // Открыть, использовать и закрыть подключение...

}

// Этот метод возвращает конкретный объект подключения

// на основе значения перечисления DataProvider.

IDbConnection GetConnection(DataProviderEnum dataProvider)

  => dataProvider switch

  {

    DataProviderEnum.SqlServer => new SqlConnection,

#if PC

    // He поддерживается в macOS

    DataProviderEnum.OleDb => new OleDbConnection,

#endif

    DataProviderEnum.Odbc => new OdbcConnection,

    _ => null,

  };

Преимущество работы с общими интерфейсами из пространства имен System.Data (или на самом деле с абстрактными базовыми классами из пространства имен System.Data.Common) связано с более высокими шансами построить гибкую кодовую базу, которую со временем можно развивать. Например, в настоящий момент вы можете разрабатывать приложение, предназначенное для Microsoft SQL Server; тем не менее, вполне возможно, что спустя несколько месяцев ваша компания перейдет на другую СУБД. Если вы строите решение с жестко закодированными типами из пространства имен System.Data.SqlClient, которые специфичны для Microsoft SQL Server, тогда вполне очевидно, что в случае смены серверной СУБД код придется редактировать, заново компилировать и развертывать.

К настоящему моменту вы написали (довольно простой) код ADO.NET, который позволяет создавать различные типы объектов подключений, специфичные для поставщика. Тем не менее, получение объекта подключения — лишь один аспект работы с ADO.NET. Чтобы построить полезную библиотеку фабрики поставщиков данных, необходимо также учитывать объекты команд, объекты чтения данных, адаптеры данных, объекты транзакций и другие типы, связанные с данными. Создание подобной библиотеки кода не обязательно будет трудным, но все-таки потребует написания значительного объема кода и затрат времени.

Начиная с версии .NET 2.0, такая функциональность встроена прямо в библиотеки базовых классов .NET. В .NET Core эта функциональность была значительно обновлена.

Вскоре мы исследуем упомянутый формальный API-интерфейс, но сначала понадобится создать специальную базу данных для применения в настоящей главе (и во многих последующих главах).

Установка SQL Server и Azure Data Studio

На протяжении оставшегося материала главы мы будем выполнять запросы в отношении простой тестовой базы данных SQL Server по имени AutoLot. В продолжение автомобильной темы, затрагиваемой повсеместно в книге, база данных AutoLot будет содержать пять взаимосвязанных таблиц (Inventory, Makes, Orders, Customers и CreditRisks), которые хранят различные данные о заказах гипотетической компании по продаже автомобилей. Прежде чем погрузиться в детали, связанные с базой данных, вы должны установить SQL Server и IDE-среду SQL Server.