Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

в коде такие типы применяются в схожей манере — в том и заключается преимущество полиморфизма на основе интерфейсов. Скажем, если определить метод, который принимает параметр IDbConnection, то ему можно передавать любой объект подключения ADO.NET:

public static void OpenConnection(IDbConnection cn)

{

  // Открыть входное подключение для вызывающего кода.

  connection.Open();

}

На заметку! Использовать интерфейсы вовсе не обязательно; аналогичного уровня абстракции можно достичь путем применения абстрактных базовых классов (таких как DbConnection) в качестве параметров или возвращаемых значений. Однако использование интерфейсов вместо базовых классов является общепринятой практикой.

То же самое справедливо для возвращаемых значений. Создайте новый проект консольного приложения .NET Core по имени MyConnectionFactory. Добавьте в проект перечисленные ниже пакеты NuGet (пакет OleDb действителен только в Windows):

Microsoft.Data.SqlClient

System.Data.Common

System.Data.Odbc

System.Data.OleDb

Далее добавьте в проект новый файл по имени DataProviderEnum.cs со следующим кодом:

namespace MyConnectionFactory

{

  // Пакет OleDb предназначен только для Windows и в .NET Core не поддерживается.

  enum DataProviderEnum

  {

    SqlServer,

#if PC

    OleDb,

#endif

    Odbc,

    None

  }

}

Если на своей машине обработки вы работаете в среде Windows, тогда модифицируйте файл проекта, чтобы определить символ условной компиляции PC:

<PropertyGroup>

  <DefineConstants>PC</DefineConstants>

</PropertyGroup>

В случае использования Visual Studio щелкните правой кнопкой мыши на имени проекта и выберите в контекстном меню пункт Properties (Свойства). В открывшемся диалоговом окне Properties (Свойства) перейдите на вкладку Build (Сборка) и введите нужное значение в поле Conditional compiler symbols (Символы условной компиляции).

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

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.

На заметку! Если ваша машина для разработки функционирует под управлением Windows и вы установили Visual Studio 2019, то уже имеете установленный экземпляр SQL Server Express (под названием localdb), который можно использовать для всех примеров в настоящей книге. В случае согласия работать с указанной версией можете сразу переходить в раздел "Установка IDE-среды SQL Server".

Установка SQL Server

В текущей главе и многих оставшихся главах книги вам будет нужен доступ к экземпляру SQL Server. Если вы применяете машину разработки, на которой установлена ОС, отличающаяся от Windows, и у вас нет доступного внешнего экземпляра SQL Server, или вы решили не использовать внешний экземпляр SQL Server, то можете запустить SQL Server внутри контейнера Docker на рабочей станции Мае или Linux. Контейнер Docker функционирует и на машинах Windows, поэтому вы можете выполнять примеры в книге с применением Docker независимо от выбранной ОС.

Установка SQL Server в контейнер Docker

В случае использования машины разработки, основанной не на Windows, и отсутствии доступного для примеров экземпляра SQL Server вы можете запустить SQL Server внутри контейнера Docker на рабочей станции Мае или Linux. Контейнер Docker работает также на машинах Windows, поэтому вы можете выполнять примеры в книге с применением Docker независимо от выбранной ОС.

На заметку! Контейнеризация является крупной темой, и в этой книге просто нет места, чтобы