45890 (Менеджер подключений к базам данных)
Описание файла
Документ из архива "Менеджер подключений к базам данных", который расположен в категории "". Всё это находится в предмете "информатика" из , которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "рефераты, доклады и презентации", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "45890"
Текст из документа "45890"
Менеджер подключений к базам данных
Андрей Майоров
Введение
Не будет большим преувеличением сказать, что львиная доля разрабатываемых сейчас программ использует в своей работе базы данных. Большинство из них работает с одной базой, более редкие представители – с двумя, тремя, четырьмя и так далее, вплоть до полной неопределенности в количестве баз на этапе разработки.
Примеры приложений, работающих с одной БД, знакомы каждому. С двумя базами может работать, например, программа, синхронизирующая данные между ними. При этом базы могут иметь разную структуру и управляться разными СУБД. С заранее неизвестным количеством баз может работать, например, приложение, собирающее статистику из множества источников.
В рамках этой статьи нас не очень интересует, что именно приложение делает с базой данных. Важен сам факт подключения для выполнения каких бы то ни было операций. Рассмотрим традиционный для 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.
Перечисление подключений
Мы уже говорили о приложениях с неопределенным на этапе разработки количеством подключений. В практике применения менеджера подключений это может выглядеть, например, так: программа должна последовательно получить информацию из каждой БД, зарегистрированной в менеджере. При этом на момент написания программы мы не знаем, какие базы, и в каком количестве будут нужны конечному пользователю.
Очевидно, что в этом случае логические имена баз нас не очень-то интересуют. Гораздо больше нам нужна возможность перебора всех баз в менеджере. Например:
| foreach( IDbConnection con in dbmgr ) { // Получаем информацию … } |
Для того чтобы эта языковая конструкция работала, да и вообще для перебора всех имеющихся подключений, наш класс DbManager должен реализовывать интерфейс IEnumerable.
Конфигурирование менеджера
Настройка менеджера заключается в установке соответствия между логическим именем подключения и информацией, достаточной для создания объекта подключения. Несложные размышления показывают, что достаточно знать тип объекта подключения, строку подключения, а также является ли данное подключение подключением по умолчанию.
Как уже указывалось, проще всего эту настройку делать через конфигурационный файл приложения. При этом и у разработчика есть единое место для описания подключений, и конечный пользователь может быстро адаптировать приложение к своим условиям. Нужно отметить, впрочем, что при этом подходе конечный пользователь должен знать стандартный формат строк подключения ADO.NET.
Примерный код, инструктирующий менеджера произвести чтение настроечных данных, даже если он уже был сконфигурирован:
| dbmgr.Configure( true ); // forceReload = true |
При этом формат секции конфигурационного файла может быть таким:
| connectionString="..." default="true" /> connectionString="..." type="OleDbConnection" /> |
Здесь декларируется, что приложение использует две базы данных. Первая из них называется alfa, обслуживается объектом типа SqlConnection (ибо ничего другого не указано), и является подключением по умолчанию. Вторая носит логическое имя beta и обслуживается объектом типа OleDbConnection. Безусловно, для обеих баз указаны и корректные строки подключений.
Имея простой и удобный способ описания подключений через конфигурационный файл, мы, тем не менее, не должны забывать, что бывают ситуации, когда все это должно быть сделано программным путем. Например, так:
| Configuration config = new Configuration(); // Настраиваем объект config … // Назначаем конфигурацию менеджеру DbManager.Configure( config ); |
В данном случае объект типа Configuration предоставляет нам те же возможности настройки, что и файл конфигурации.
Очень тяжело представить приложение, в котором существовало бы несколько отдельных наборов подключений к базам данных. Я говорю, например, о ситуации, когда в двух разных местах приложения мы используем два разных подключения с именем beta. Какие выводы из этого следуют?
Во-первых, это значит, что все экземпляры менеджера подключений, используемые в приложении, должны быть сконфигурированы одинаково. Соответственно, методы Configure(…) мы смело можем делать статическими.
Во-вторых, напрашивается вывод, что мы вполне можем обойтись одним экземпляром менеджера на все приложение. В некоторых случаях, о которых мы поговорим позже, нам понадобится большее, но все же ограниченное количество экземпляров. Из этого следует, что экземпляр менеджера мы должны получать не при помощи оператора new, а посредством некоего статического метода класса. Пример:
| DbManager dbmgr = DbManager.Get(); |
Подобный подход напоминает о 
паттерне проектирования Singleton, но, в отличие от классической трактовки, у нас может быть не один экземпляр, а несколько. Впрочем, об этом мы еще поговорим.
Структура класса
Продумав сценарий использования менеджера, мы можем спроектировать структуру класса. Вот она:
| public class DbManager : IEnumerable { public static DbManager Get() {...} public IDbConnection this[string name] { get {...} } public IDbConnection Default { get {...} } public static void Configure( bool forceReload ) {...} public static void Configure( Configuration config ) {...} public IEnumerator GetEnumerator() {...} // Непубличные методы и члены класса ... } |
Краткое описание методов:
Get – возвращает менеджер подключений. Если экземпляра менеджера еще нет, создается новый.
this[ string ] – возвращает объект подключения по данному логическому имени. В том случае, если имя не указано (равно null), возвращается объект подключения по умолчанию.
Default – возвращает объект подключения по умолчанию.
Configure( bool ) – читает настроечную информацию из конфигурационного файла. Если мы пытаемся работать с еще не сконфигурированным менеджером, он должен автоматически вызвать этот метод.
Configure( Configuration ) – настраивает менеджер в соответствии с данным конфигурационным объектом.
GetEnumerator – позволяет пробежаться по всем подключениям менеджера циклом foreach.
Варианты работы с базой
Мы уже рассматривали кусок типового кода, работающего с базой. Более полный фрагмент выглядит так: мы сначала создаем подключение (например, SqlConnection), потом создаем команду (SqlCommand), добавляем к команде параметры, ассоциируем ее с подключением, открываем подключение, выполняем команду, закрываем подключение:
| SqlConnection con = new SqlConnection(); con.ConnectionString = "..."; SqlCommand cmd = new SqlCommand(); cmd.CommandText = "..."; cmd.Connection = con; cmd.Parameters.Add( new SqlParameter( ... ) ); using( con ){ con.Open(); cmd.Execute(); ... } |
Мы делаем это при каждом обращении к базе, так что возникает вопрос: а не будет ли быстрее заранее создать и сохранить подключение и команду, а потом только использовать их? С точки зрения элементарной логики кажется очевидным, что должно быть быстрее. С другой стороны, известно, что создание объектов в .NET Framework происходит очень быстро, так что выигрыш вряд ли будет большим.
Проведем тест. В одном прогоне мы будем каждый раз создавать подключение и команду, а в другом – использовать готовые объекты. Команде определим три параметра. В двух прогонах по 100 000 итераций удалось выяснить следующее:
Первый подход, при котором все создается заново, примерно на 5 процентов медленнее второго.
В абсолютном исчислении это замедление составляет всего 0.08 миллисекунды на каждую итерацию, т.е. очень мало. Если учесть, что само обращение к базе выполняется на несколько порядков медленнее создания любого объекта, то выигрыш получается и вовсе умозрительный.
Какие выводы? Во-первых, логика восторжествовала – не создавать объекты оказалось быстрее, чем создавать. Во-вторых, это совершенно не важно. Разница в скорости между пересозданием объектов и использованием готовых настолько мала, что разработчик может смело выбирать тот или иной подход, руководствуясь только своим личным пониманием прекрасного.
