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

Наконец, вы видите, что IDataReader расширяет интерфейс IDataRecord, определяющий большой набор членов, которые позволяют извлечь из потока строго типизованное значение вместо общего объекта System.Object, предлагаемого перегруженным методом индексатора объекта чтения данных. Вот часть программного кода соответствующих методов GetXXX, определенных в рамках IDataRecord (весь программный код можно найти в документации .NET Framework 2.0 SDK).

public interface IDataRecord {

 int FieldCount { get; }

 object this[string name] { get; }

 object this[int i] { get; }

 bool GetBoolean(int i);

 byte GetByte(int i);

 char GetChar(int i);

 DateTime GetDateTime(int i);

 Decimal GetDecimal(int i);

 float GetFloat(int i);

 short GetInt16(int i);

 int GetInt32(int i);

 long GetInt64(int i);

 …

 bool IsDBNull(int i);

}

Замечание. Перед чтением значения из объекта чтения данных можно использовать метод IDataReader.IsDBNull, чтобы программно убедиться в том, что соответствующее поле данных не равно null (и не допустить генерирования соответствующего исключения в среде выполнения).

Интерфейсы и абстрактные поставщики данных

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

public static void OpenConnection(IDbConnection cn) {

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

 cn.Open;

}

То же можно сказать и о возвращаемых значениях. Рассмотрите, например, следующую простую программу на C#, которая позволяет вызывающей стороне получить конкретный объект соединения, используя значение пользовательского перечня (здесь предполагается, что вы указали оператор using для System.Data).

namespace ConnectionApp {

 enum DataProvider { SqlServer, OleDb, Odbc, Oracle }

 class Program {

  static void Main(string[] args) {

   // Получение соединения.

   IDbConnection myCn = GetConnection(DataProvider.SqlServer);

   // Требуется соединение с базой данных SQL Server Pubs.

   myCn.ConnectionString = "Data Source=localhost;uid=sa;pwd=;Initial Catalog=Pubs";

   // Открытие соединения с помощью вспомогательной функции.

   OpenConnection(myCn);

   // Использование соединения и его последующее закрытие.

   …

   myCn.Close;

  }

  static IDbConnection GetConnection(DataProvider dp) {

   IDbConnection conn = null;

   switch (dp) {

   case DataProvider.SqlServer:

    conn = new SqlConnection;

    break;

   case DataProvider.OleDb:

    conn = new OleDbConnection;

    break;

   case DataProvider.Odbc:

    conn = new OdbcConnection;

    break;

   case DataProvider.Oracle:

    conn = new OracleConnection;

    break;

   }

   return conn;

  }

 }

}

Преимущество использования общих интерфейсов System.Data заключается в том, что в этом случае у вас больше шансов создать более гибкий программный код, который дольше сможет оставаться актуальным. Например, если сегодня вы построите приложение, использующее Microsoft SQL Server, то что вы сможете сделать, если через год-другой руководство вашей компании примет решение перейти на использование Oracle? Если в приложении "жестко" запрограммированы имена типов System.Data.SqlClient, то вам, очевидно, придется сначала их отредактировать, а затем перекомпилировать и повторно инсталлировать компоновочный блок.

Файлы конфигурации и гибкость приложений