Сохранение независимости базы данных приложения (ADO.NET против инкапсуляции логики БД)

Примечание. Этот ответ актуален, если вы решили использовать базовые функции ADO.NET 2 вместо ORM (например, Entity Framework или NHibernate) или LINQ to SQL.

Предположим, у вас есть строка подключения, определенная в вашем app.config:

<connectionStrings>
    <add name="SomeConnection"
         providerName="System.Data.SqlClient"
         connectionString="..." />
</connectionStrings>

Обратите внимание на наличие атрибута providerName и его значения. Вы также можете указать значение для другого поставщика БД, например. System.Data.SQLite.

(Обратите внимание, что нестандартные поставщики, т. е. те, которые не входят в .NET Framework по умолчанию, нужно сначала зарегистрироваться либо в app.config, либо в клиентской машине machine.config.)

Теперь вы можете работать с указанной базой данных полностью независимо от поставщика следующим образом:

using System.Configuration;  // for ConfigurationManager
using System.Data;           // for all interface types
using System.Data.Common;    // for DbProviderFactories

var cs = ConfigurationManager.ConnectionStrings["SomeConnection"];
//                                              ^^^^^^^^^^^^^^^^

var factory = DbProviderFactories.GetFactory(cs.ProviderName);
//                                           ^^^^^^^^^^^^^^^

using (IDbConnection connection = factory.CreateConnection())
{
    connection.ConnectionString = cs.ConnectionString;
    //                            ^^^^^^^^^^^^^^^^^^^
    connection.Open();
    try
    {
        using (IDbCommand command = connection.CreateCommand())
        {
            ...  // do something with the database
        }
    }
    finally
    {
        connection.Close();
    }
}

Обратите внимание, что этот код работает только с типами интерфейса. Единственное место, где вы указываете конкретного поставщика БД, — это значение атрибута providerName в файле app.config. (Я отметил все места, где берется настройка из app.config, с помощью ^^^s.)

Дальнейшее чтение:

• Общее кодирование с помощью ADO. NET 2.0 Base Classes and Factory:
  похоже на мой ответ, но более подробно.

• Центр разработчиков управляемых поставщиков ADO.NET и набора данных:
  включает, среди прочего, указатель доступных поставщиков баз данных ADO.NET.

ИМХО, использование ORM является хорошим дизайнерским решением для создания приложения, не зависящего от базы данных. Переключение базы данных может быть таким же простым, как изменение параметра конфигурации и строки подключения.

Вам не нужно OleDbConnection для доступа к неспецифическим поставщикам ADO.NET. Просто используйте DbConnection et. др. См. DbProviderFactories в MSDN для получения дополнительной информации.

Включив Oracle в этот список, вы гарантировали, что все будет просто.

• Oracle использует другой символ префикса (двоеточие) для параметров по сравнению с SQL Server, который использует символ "at".
• Oracle использует один тип данных (число) для long, int, short, boolean, float и decimal; ваш код должен быть уверен, что вы сопоставляете их правильно.
• Вы должны параметризовать значения даты и времени Oracle; если вы попытаетесь использовать строки для дат в своих операторах SQL, вы сойдете с ума из-за формата даты Oracle. (Oracle использует трехсимвольную аббревиатуру месяца в формате 01-JAN-2010.)
• Базовые функции SQL для обработки пустых значений могут быть разными, особенно для объединения нулевых значений. («NVL» по сравнению с «COALESCE») Oracle гораздо более требователен к зарезервированным словам.
• Oracle не имеет встроенной поддержки столбцов идентификаторов. Обходные пути включают последовательности, триггеры и требование транзакций только для извлечения значения идентификатора из новой строки.

Другими словами, ваше приложение не может быть независимым от БД. Если вы не используете ORM, вам обязательно нужно создать уровень доступа к данным, который скроет все эти вещи от остальной части приложения.

Голос опыта здесь. Просто говорю'. Для общей схемы для SQL Server и Oracle нам пришлось построить большую часть инфраструктуры ORM, избегая при этом аспектов, которые могут снизить производительность. Интересно, но нетривиально, однозначно!

LINQ — высоко оцененный .NET ORM, отчасти потому, что вы можете использовать его и хранимые процедуры. Проблема в том, что это только SQL Server, но люди работают над тем, чтобы обеспечить аналогичную функциональность для Oracle и MySQL.

Что касается оптимизации базы данных и запросов, я съеживаюсь при мысли об использовании ORM. Типы данных, функции и общий синтаксис не очень переносимы в SQL. Наиболее эффективным средством взаимодействия с каждой базой данных будет адаптация модели и запросов к каждой из них, но это требует опыта, времени и денег. При необходимости сосредоточьтесь на одном поставщике базы данных с настройкой кода для поддержки замены поставщика и добавьте поддержку других баз данных по мере необходимости.

Нет веских причин избегать наиболее универсальных интерфейсов с самой широкой поддержкой — OleDb и даже ODBC, если они вас устраивают. Все, что выходит за рамки этого, сокращает количество продуктов/языков/платформ/инструментов/разработчиков, с которыми вы можете работать. Будучи ближе всего к металлу SQL, поставщик не собирается привносить большую неэффективность - определенно меньше, чем более эзотерические варианты. Они были вокруг долгое, долгое время, чтобы отжать любые проблемы.

Если вы собираетесь добавить уровень абстракции (своего или чужого), то это следует решать на основе достоинств абстракций, представленных в вашем конкретном контексте, а не просто иметь слой абстракции (который просто обеспечивает дополнительную поддержку, если только есть преднамеренная выгода.)

Как видите, пробег у всех разный. :) А вообще, я думаю чем проще, тем лучше.

Почему бы не использовать Patterns & Practices корпоративную библиотеку Блок приложений для доступа к данным. Накладные расходы минимальны, а смена провайдера выполняется очень быстро.

Цитировать:

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

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

Таким образом, вы получаете развязку при использовании DAL, но пользу от улучшений производительности или специфичных для поставщика конструкций в DAL.