Библиотека сайта rus-linux.net
SQLAlchemy
Глава 20 из книги "Архитектура приложений с открытым исходным кодом", том 2.Оригинал: SQLAlchemy
Автор: Michael Bayer
Перевод: А. Панин
20.2. Дихотомия между основными задачами и объектно-реляционным отображением
Основной задачей, поставленной при разработке SQLAlchemy, было предоставление тулкита, который раскрывал бы каждый уровень взаимодействия с базой данных в рамках богатого набора функций API, разделяя задачи на две основных категории, известные как основные (Core) и связанные с объектно-реляционным отображением (ORM). Основные задачи заключаются во взаимодействии с API для работы с базами данных языка Python (DBAPI), выводе текстовых выражений SQL, понятных базе данных, а также управлении схемами. Все эти возможности доступны через публичные API. ORM, или объектно-реляционное отображение реализуется в рамках специфической библиотеки, созданной для работы с основными функциями системы. Объектно-реляционное отображение, реализуемое в рамках SQLAlchemy, является одним из неограниченного количества возможных уровней абстракции объектов, которые могут быть реализованы с использованием основных функций, причем многие разработчики и организации создают свои приложения, непосредственно использующие основные функции системы.
Рисунок 20.1: Диаграмма уровней SQLAlchemy
Разделение на основную часть и объектно-реляционное отображение всегда было наиболее характерной чертой SQLAlchemy, при этом данная черта имеет как достоинства, так и недостатки. Явно реализованная основная часть SQLAlchemy предполагает установление связи между атрибутами класса объектно-реляционного отображения и структурой, известной как Table, вместо непосредственной связи с названиями столбцов в строковом формате, как это установлено в базе данных; осуществление запроса SELECT с использованием структуры с именем select вместо объединения атрибутов объектов непосредственно с выражениями в строковой форме; а также прием результирующих строк с использованием фасадного класса с именем ResultProxy, который прозрачно отображает структуру select на каждую из результирующих срок вместо передачи данных непосредственно от курсора из базы данных в заданный пользователем объект.
Элементы основной части могут быть незаметны в очень простых приложениях, использующих объектно-реляционное отображение. Однако, из-за того, что основные функции тщательно интегрированы в код объектно-реляционного отображения для предоставления возможности плавного перехода между конструкциями объектно-реляционного отражения и основной системы, более сложное приложение на основе объектно-реляционного отображения может "перейти ниже" на один или несколько уровней для того, чтобы осуществлять взаимодействие с базой данных более специфическим и оптимизированным способом в зависимости от ситуации. По мере развития проекта SQLAlchemy API основной части становился менее пригодным для регулярного использования, в то время, как объектно-реляционное отображение продолжает предоставлять более изощренные и обобщенные шаблоны. Тем не менее, доступность основной части также внесла свою лепту в ранний успех системы SQLAlchemy, так как это обстоятельство позволило пользователям ранних версий достичь гораздо лучших результатов, чем те, которые могли быть достигнуты при использовании разрабатываемой системы объектно-реляционного отображения.
Недостатком подхода, заключающегося в разделении системы на основную часть и объектно-реляционное отображение, является большее количество шагов, требующихся для доставки инструкций. Стандартная реализация интерпретатора языка программирования Python, созданная с использованием языка программирования C, известна значительными затратами ресурсов на осуществление отдельных вызовов функций, которые являются основной причиной снижения производительности в процессе работы приложения. Традиционные методы обхода этой проблемы заключаются в сокращении цепочек вызовов функций путем перераспределения кода и включения кода в состав существующих функций, а также в замене требующих высокой производительности фрагментов кода на код на языке C. Разработчики SQLAlchemy потратили много лет на использование двух описанных выше методов с целью повышения производительности системы. Однако, продолжающееся распространение интерпретатора PyPy для языка Python может решить оставшиеся проблемы с производительностью без необходимости переписывания большей части внутреннего кода SQLAlchemy на языке C, так как PyPy значительно сокращает потерю производительности при использовании длинных цепочек вызовов функций, применяя inline-функции в ходе процесса JIT-компиляции.
Продолжение статьи: Использование DBAPI