Каков наилучший подход к созданию приложения для работы с несколькими поставщиками ado.net?

Question

Мы разрабатываем набор промышленных приложений, использующих SQL Server.

По мере расширения спроса клиенты хотят использовать наши приложения со своими собственными СУБД, такими как Oracle, MySQL и др.

В настоящее время некоторые приложения используют поставщик OLEDB, а другие используют собственный SQLServer по разным причинам, включая опыт программирования и религию.

Мы ищем единый подход. Руководитель проекта предпочитает OLEDB, потому что «он работает со всем». Лично я ненавижу это, потому что, как обрабатываются параметры запросов ...

Я имею в виду два решения:

Первый - использовать SQLOLEDB, сохраняя существующий код, и адаптировать каждый оператор SQL в случае несовместимости с помощью инструкций ветвления. Это будет происходить очень быстро, SQL не будет сильно отличаться, и это порадует менеджера проекта. Однако это может превратить код в спагетти.

Вторым будет использование собственного поставщика ADO.NET для каждой СУБД и разработка библиотеки доступа к данным для каждой. Каждая библиотека может содержать общую часть, чтобы избежать дублирования кода. Конечно, это займет некоторое время, но это приведет к чистой архитектуре и оптимальной производительности.

В основном это клиент-серверные приложения. Некоторые части нашей базы данных генерируются динамически, и существует множество динамических запросов. Вот почему использование ORM невозможно.

Как бы вы попытались достичь той же цели?

Answer 1

Я бы сделал одну из двух вещей:

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

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

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

Это просто случай наличия фабрики для обеспечения конкретной реализации для данного интерфейса.

Answer 2

В вашей библиотеке убедитесь, что вы используете только базовые классы в пространстве имен System.Data.Common.

Таким образом, вместо SqlCommand используйте DbCommand и т. Д.

Вы можете внедрить фактическую реализацию в DAL.

public class MyDal
{
  private cmd DbCommand;

  public MyDal(DbCommand command)
  {
      cmd = command;
  }
}

В качестве альтернативы, напишите свою собственную абстракцию (интерфейс / абстрактный класс), напишите классы реализации для нее, которые обертывают реализацию другого провайдера, и используйте это.