Менеджер подключений к базам данных Андрей Майоров Введение
    Не будет большим преувеличением сказать, что львиная доля разрабатываемых сейчас программ использует в своей работе базы данных. Большинство из них работает с одной базой, более редкие представители - с двумя, тремя, четырьмя и так далее, вплоть до полной неопределенности в количестве баз на этапе разработки.
    Примеры приложений, работающих с одной БД, знакомы каждому. С двумя базами может работать, например, программа, синхронизирующая данные между ними. При этом базы могут иметь разную структуру и управляться разными СУБД. С заранее неизвестным количеством баз может работать, например, приложение, собирающее статистику из множества источников.
    В рамках этой статьи нас не очень интересует, что именно приложение делает с базой данных. Важен сам факт подключения для выполнения каких бы то ни было операций. Рассмотрим традиционный для ADO.NET сценарий работы с базой.
    Во-первых, мы должны знать строку подключения (connection string), во-вторых, создать объект подключения соответствующего типа, затем проинициализировать его этой строкой, открыть и начать использовать. По завершению использования объект подключения следует уничтожить. Выглядит это примерно так: string conString = "..."; SqlConnection con = new SqlConnection(); con.ConnectionString = conString; using( con ){ con.Open(); ... } // В этой точке подключение будет автоматически закрыто и уничтожено Код прост и логичен, но в реальном приложении с ним могут возникнуть проблемы:
    Почти всегда разработка приложения ведется не с теми строками подключения, которые будут использоваться при эксплуатации. Соответственно, мы не можем жестко зашить строку подключения в код, а должны как-то ввести ее во время работы приложения.
    В ряде приложений разработчик не знает конкретного типа объекта подключения и работает с базовым интерфейсом IDbConnection. Для таких случаев код типа "new SqlConnection" не годится.
    В то же время разработчик обычно четко представляет, какое подключение ему нужно открыть, и может логически обозначить его "база А" или "база Б", что бы это ни означало в среде конечного пользователя. В случае приложения с одной базой, можно подключаться и к некоторой базе по умолчанию, никак ее не именуя.
    Очевидно, что удобным решением могло бы стать использование некоторого механизма, позволяющего получать объект подключения к базе данных по его логическому имени. Конечному пользователю этот механизм должен предоставлять возможность быстро и просто ассоциировать логическое название с реальной строкой подключения. Например, это можно делать в файле конфигурации. Подобный механизм мы и назовем "менеджером подключений к базам данных". Основная функция менеджера
    Основная функция менеджера - по заданному логическому имени вернуть объект подключения нужного типа, проинициализированный нужной строкой подключения.
    В использовании это может выглядеть так:
    SqlConnection c1 = (SqlConnection)dbmgr["beta"];
    IDbConnection c2 = dbmgr.Default; Приведение типа в первой строке обусловлено тем, что наше приложение может работать с базами разных типов, и, следовательно, менеджер не может возвращать объект подключения какого-то определенного типа. Так как любой объект подключения должен реализовывать интерфейс IDbConnection, менеджеру наиболее логично давать доступ к объектам именно через этот интерфейс.
    Очевидно, что эта функция менеджера примерно соответствует шаблону (паттерну) проектирования Factory Method. Перечисление подключений
    Мы уже говорили о приложениях с неопределенным на этапе разработки количеством подключений. ............