Реферат: Менеджер подключений к базам данных

wasOpened = true;

}

try {

// Используемподключение

…

}

finally

{

if( wasOpened ) connection.Close();

}

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

Используем для решения тот же механизм детерминированной деструкции – интерфейс IDisposable, который столь упрощает использование подключения по стандартной схеме. Нам достаточно создать класс, который при конструировании открывал бы подключение, если это необходимо, а при уничтожении – закрывал бы, если открывал его сам. При этом мы можем сделать класс достаточно умным, чтобы он понимал, в каком режиме работает менеджер подключений. Если менеджер не кэширует объекты, наш сервисный класс будет удалять их в конце блока using.

В использовании это будет выглядеть примерно так:

using( new DbOpen( connection )) { // Используем подключение, раз открывали! … }

Отметим также, что при конструировании экземпляра класса подключение открывается автоматически. Таким образом, еще одна строка в стандартном сценарии становится ненужной.

Реализация

Данный подход уже реализован и неоднократно прошел полевые испытания. Более подробно о готовом модуле можно узнать на http://www.byte-force.com/russian/products/tech/lsddatabase.html.

Ссылки

E. Gamma, et al., Design Pattern: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995

ПРИМЕЧАНИЕ От редакции Многие участники редакционной коллегии, имеющие опыт работы с базами данных, неоднозначно расценивает данную статью. С одной стороны, идея инкапсуляции работы с подключениями, позволяющая получать подключения по логическим именам, хороша. Она упрощает код, тем самым снижая вероятность появления ошибок. С другой стороны, создание самодельного пула, а также реализация закрытия соединения и многопоточной работы, является успешным решением собственноручно созданной проблемы. Более того, так как кэш может возвращать один и тот же экземпляр подключения при разных вызовах, в программе может возникнуть ошибка из-за случайного (неявного) использования одного подключения в разных алгоритмах. То есть велика вероятность того, что программист в двух алгоритмах попытается создать две независимых транзакции, но поскольку соединение физически одно, это ему не удастся. Как, собственно, заметил сам автор, выигрыша в скорости такое решение не дает, и смысл кэширования просто непонятен. Таким образом, мы рекомендуем использовать на практике идею инкапсуляции работы с подключениями, но не кэширование подключений. Однако изучение этой части статьи интересно, так как в ней используются методы оптимизации, вполне применимые в других случаях.