Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Lines Club

Ищем достойных соперников.

Библиотека сайта rus-linux.net

SQLAlchemy

Глава 20 из книги "Архитектура приложений с открытым исходным кодом", том 2.

Оригинал: SQLAlchemy
Автор: Michael Bayer
Перевод: А. Панин

20.2. Дихотомия между основными задачами и объектно-реляционным отображением

Основной задачей, поставленной при разработке SQLAlchemy, было предоставление тулкита, который раскрывал бы каждый уровень взаимодействия с базой данных в рамках богатого набора функций API, разделяя задачи на две основных категории, известные как основные (Core) и связанные с объектно-реляционным отображением (ORM). Основные задачи заключаются во взаимодействии с API для работы с базами данных языка Python (DBAPI), выводе текстовых выражений SQL, понятных базе данных, а также управлении схемами. Все эти возможности доступны через публичные API. ORM, или объектно-реляционное отображение реализуется в рамках специфической библиотеки, созданной для работы с основными функциями системы. Объектно-реляционное отображение, реализуемое в рамках SQLAlchemy, является одним из неограниченного количества возможных уровней абстракции объектов, которые могут быть реализованы с использованием основных функций, причем многие разработчики и организации создают свои приложения, непосредственно использующие основные функции системы.

Диаграмма уровней 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


Эта статья еще не оценивалась
Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.

Комментарии отсутствуют