Работа с реляционными таблицами, хранящимися в файлах БД, является одним из самых сильных мест системы Clarion. Схема БД (структура и взаимосвязь таблиц) хранится в специальном словаре данных. Словарь данных определяет первый уровень абстракции. Вторым уровнем абстракции является язык шаблонов (и прежде всего встроенные переменные, обеспечивающие интерфейс со словарем). На этом уровне в соответствии со словарем формируется логика связей с учетом отношений, ограничений ссылочной целостности, диапазонов представления значений и т.п. (все то, что ныне называется модным термином "бизнес-правила"). Третий уровень абстракции, на который производится отображение первых двух, - это язык определения данных, являющийся неотъемлемой частью языка Clarion. Помимо реляционных таблиц (FILE), на нем описываются и вспомогательные структуры QUEUE (список записей, хранящийся в оперативной памяти) и VIEW (виртуальная таблица). Четвертый уровень абстракции - это язык манипулирования данными, также неразрывно связанный с языком Clarion. Для него характерны операторы файлового доступа (OPEN, CREATE, PACK, STREAM, FLUSH, REMOVE, RENAME), операторы модификации данных (ADD, APPEND, DELETE, PUT), операторы блокировки доступа (LOCK, UNLOCK, HOLD, RELEASE), операторы позиционирования (SET, NEXT, PREVIOUS, SKIP, GET), операторы поддержки транзакций (COMMIT, LOGOUT, ROLLBACK), а также вспомогательные операторы (POSITION, POINTER, RECORDS, EOF, SEND). Пятый уровень абстракции - это уровень внутренней унификации работы с таблицами разных СУБД (механизм замещаемых драйверов БД). Именно здесь проходит "водораздел" между стандартной и профессиональной редакцией среды Clarion (в поставке стандартной версии обеспечивается работа только с драйверами форматов CLARION и TOPSPEED). Форма физического представления реляционных таблиц (и специфика работы с ними) должна оказывать минимальное воздействие на разработку информационных приложений. Вот почему разработчики Clarion реализовали этот механизм еще в версии Clarion Database Developer 3.0 (для DOS), созданной около 6 лет назад. Суть его состоит в том, что вся работа ведется через абстрактное понятие таблицы (файла). Конкретизация же физического представления осуществляется в атрибуте DRIVER структуры FILE. Для перехода на работу с другим представлением часто достаточно просто сменить символьную строку в атрибуте DRIVER, отвечающую за подключение соответствующей DLL-библиотеки. Понятно, что простого переключения может оказаться недостаточно, поэтому специфика работы с различным физическим представлением таблиц в технологии Clarion осуществляется за счет поддержания многообразия типов данных (в системе типов языка Clarion представлены практически все возможные типы, которые могут встретиться в таблицах других СУБД), и за счет оптимизации доступа (настройки параметров конкретного драйвера). При переносе Clarion в среду Windows к драйверам Btrieve, FoxPro, Clipper, dBase3, dBase4, DOS, ASCII и BASIC добавились драйвер ODBC и прямые SQL-драйверы для промышленных СУБД. Шестой уровень абстракции - уровень внешней унификации работы с таблицами разных СУБД, который опирается на ставшую стандартом де-факто для платформы Wintel спецификацию ODBC (Open DataBase Connectivity). Работа в рамках ODBC строится по трехзвенной цепочке: первичный (front-end) ODBC-драйвер со стороны языка Clarion, стандартный менеджер ODBC (как связующий элемент) и вторичный (back-end) ODBC-драйвер, обеспечивающий доступ к источнику данных в формате конкретной СУБД. Понятно, что такое количество промежуточных слоев, да еще реализованных разными фирмами, может сказаться на функциональности интерфейса (типы данных, возврат результатов запросов, нюансы совместимости) и, что особенно важно, на производительности. Что касается последних сомнений, то быстродействие нынешнего поколения многих ODBC-средств таково, что для той же системы Clarion падение производительности по сравнению с прямыми SQL-драйверами составляет всего лишь около 15-20%.
Таким образом, мы вплотную подошли к седьмому уровню абстракции работы с базами данных в технологии Clarion, а именно, к уровню SQL-драйверов. Именно он и позволяет обеспечить достаточно полноценную работу в архитектуре клиент/сервер, вне зависимости от того, какой моделью доступа к удаленным данным вы пользуетесь (RDA, DBS или AS). В случае RDA-модели (Remote Data Access) логика обработки практически целиком исполняется на клиентской части. И именно эта модель достаточно легко может быть реализована при интеграции Clarion-приложения (как клиентской части) с сервером баз данных. Однако этому уровню в наибольшей степени подходит использование ODBC, а не SQL. В случае DBS-модели (DataBase Server) большая часть логики обработки перекочевывает с клиента на сервер. Здесь уже требуется активно задействовать механизмы хранимых процедур и триггеров БД. Для этого случая больше подходит использование прямых SQL-драйверов. Здесь уже можно задействовать специфику того или иного SQL-сервера (SQL-хинты, script-файлы и т.п.). Эффективность взаимодействия с SQL-сервером из Clarion-приложения можно повысить за счет использования механизма свойств (property), встроенного в язык Clarion для доступа к методам ненаследуемых классов. В случае же AS-модели (Application Server) между клиентом и сервером данных появляется третье, промежуточное звено, задача которого разгрузить сервер данных, почти полностью убрав с него логику. Реализация AS-модели взаимодействия с помощью Clarion также возможна, но является наименее проработанной. Как известно, центральную роль в этой модели играют мониторы обработки транзакций, а штатных решений стыковки с ними ни на уровне шаблонов, ни на уровне API-интерфейсов система Clarion пока не предоставляет.
Необходимость учета специфики работы с SQL-серверами позволяет в полную силу задействовать возможности механизма шаблонов. Ведь именно вариативное программирование, которое в Clarion может быть реализовано на более высоком уровне абстракции, нежели простая и привычная условная компиляция, позволяет эффективно решить задачу объединения общего с частным. Чисто технологически это открывает и путь для более четкого разделения труда в командах разработчиков: теперь результаты работы специалистов по организации интерфейса с SQL-серверами могут быть представлены в формальном виде, пригодном для непосредственного использования разработчиками другой специализации. SQL-шаблоны Энди Степлтона в этом смысле - хороший опыт, который стоит взять на вооружение.
Знаете ли Вы, что модульность - это такая организация объектов, когда они заключают в себе полное определение их характеристик, никакие определения методов и свойств не должны располагаться вне его, это делает возможным свободное копирование и внедрение одного объекта в другие.
