KISS Virtual XML RDBMS. Новая система разработки клиентских desktop и web приложений

Эта статья является первой из серии статей посвященных новой Системе, предназначенной для разработки клиентских приложений.

Назначение Системы

Название Системы (KISS Virtual XML RDBMS) очень точно определяет ее назначение и особенности. KISS (Keep It Simply Stupid) - это аббревиатура известного принципа программирования, которому следовал Разработчик Системы. Автор Системы наглым образом присвоил названию Системы эту аббревиатуру. Если Вы ознакомитесь с данной Системой, то станет очевидно, что для использования этого названия есть все основания. Просто - это ни в коем случае не означает примитивно. Это лишь означает, что Система решает самые сложные задачи предельно простым образом. Virtual XML RDBMS (Virtual XML Relational Data Base Management System) - означает, что для работы с базами данных любых реляционных СУБД Система использует виртуальную СУБД, которая работает с виртуальной XML базой данных.

Система является альтернативой таким инструментам разработки, как Visual Basic, Visual FoxPro, Delphi, С# и т.п. Система является альтернативой, но не аналогом указанных выше систем, поскольку она принципиально отличается от них архитектурой и языком программирования.

Ниже показан скриншот Основного окна приложения, в котором можно увидеть Конструктор объектов, являющийся одним из основных интерактивных инструментов разработки Системы, окно Редактора программного кода и Основное меню Системы.

Причины появления и цель разработки

Появление новой Системы разработки и нового языка программирования, лежащего в основе этой Системы оказалось очень своевременным.

Технический долг большинства существующих систем и языков программирования достиг таких масштабов, что возможность их дальнейшего эволюционного развития вызывает обоснованное сомнение. Это касается также операционных систем и любых других программных продуктов, созданных несколько десятилетий назад, а если учесть тот факт, что новые языки появляются не на пустом месте, а, как правило, используют парадигму одного или даже нескольких "старых" языков, то их перспектива не очень сильно отличается от перспективы наследуемых языков.

Стало очевидным несоответствие новых требований к программным продуктам, которые хорошо понятны большинству разработчиков, возможностям программных продуктов, попавших в капкан технического долга.

Есть еще одна "горячая" проблема, даже более острая, чем технический долг, и напрямую не связанная с программированием. Это политика ограничений по политическим или финансовым мотивам, проводимая крупнейшими IT-компаниями. Нет никакой уверенности в том что, выбрав для своей разработки какой либо известный инструмент, Вы работаете не на корзину.

Целью разработки Системы было обеспечение разработки универсальных клиентских приложений (desktop и web приложений), максимально стабильных и независимых от платформы и любых других внешних обстоятельств. Многочисленные зависимости - это еще один бич современного программирования. Разработчик Системы старался придерживаться принципа: "все свое ношу с собой"

Парадигма языка программирования

Система не имеет технического долга, поскольку создана с нуля. Поэтому ее Разработчик был ограничен только рамками здравого смысла и собственным представлением о том, каким должна быть современная Система разработки клиентских приложений. То есть Система - это авторский взгляд "незамыленным глазом" на программирование вообще и на объектное программирование и системы управления базами данными, в частности.

Нет ничего удивительного в том, что Разработчик Системы вышел за рамки парадигмы объектно-ориентированного программирования. Это не означает, что были оспорены фундаментальные понятия ООП, разве что использовалась их расширенная интерпретация. Для решения заявленных целей в Системе появились новые понятия объектного программирования, такие как:

• фундаментальные свойства, процедуры и классы

• квази родительские классы

• объектные подложки и оболочки

• пост-определение объекта и еще много чего интересного.

Объектная модель Системы была дополнена объектной моделью данных, аналога которой в ООП практически нет. В результате Объектная модель Системы стала полной и приняла вид дерева с корнем empty и двумя ветками data и control. То есть произошло строгое разделение всех базовых классов на классы объектов данных и классы управляющих объектов, что сильно упростило архитектуру Системы и предоставило новые уникальные функциональные возможности.

Система является чисто объектной, т.е. все задачи решаются исключительно лишь объектными средствами.

Виртуальная СУБД

Для обеспечения реальной независимости клиентского Приложения от физической организации внешних данных Система использует виртуальную СУБД. Приложение пользователя работает только с ней и ничего "не знает" о типе используемых физических СУБД, что делает это Приложение СУБД-независимым. При этом Система сама генерирует необходимые SQL-команды на основании сделанных Вами определений запроса. Прямое обращение из Приложения к физическим СУБД посредством SQL-запросов в Системе не предусмотрено. Исключение является конструктор DB Workbench, предназначенный для администрирования баз данных, где Администратор базы данных может "пообщаться" c любой физической СУБД на ее родном языке. Одна из страниц конструктора является аналогом стандартной Консоли реляционных СУБД.

В виртуальной базе данных можно одновременно использовать таблицы из нескольких различных физических СУБД. При этом виртуальная СУБД поддерживает связи между записями разнородных таблиц стандартным для Системы способом.

В любой момент времени Вы можете сменить тип используемых физических СУБД с помощью функции копирования таблиц из конструктора DB Workbench. При этом разработанное Приложение этого "не заметит", поскольку оно работает только с виртуальной СУБД.

Объектная модель виртуальной СУБД является универсальным объектным аналогом словаря (метаданных), используемого в любых физических СУБД. Причем, виртуальная СУБД является не просто объектной оболочкой над словарной системой физических СУБД, но и самостоятельной полноценной системой управления, поскольку берет на себя выполнение самых сложных и затратных по времени функций физических СУБД, а именно:

• управление связями.

• создание и выполнение сложных запросов с участие нескольких таблиц

• контроль доступа к базе данных.

С указанными выше функциями виртуальная СУБД справляется значительно эффективнее, чем любая физическая СУБД.

Виртуальная СУБД является системой управления XML базой данных, поскольку записи физических таблиц представлены в Системе не линейным списком полей, а XML-документом, т.е. структурой произвольной вложенности, конечные узлы (атрибуты) которой привязываются к соответствующим им полям и квази-полям физической записи или к выражению над другими атрибутами (вычисляемые атрибуты).

Классическая реляционная база данных является всего лишь частным случаем XML базы данных, когда записи физических таблиц представлены одноуровневыми XML-документами.

Использование объекта element из указанной выше объектной модели данных удалось устранить когнитивный диссонанс между реляционной моделью данных (список полей) и XML-моделью данных (структура произвольного уровня вложенности). Объект базового класса element как раз и явился таким объектом-интегратором, сделав эти совершенно разные модели совместимыми. В результате удалось создать первую эффективную систему управления XML базами данных.

Напомню очень кратко, что в настоящий момент существует два основных типа XML баз данных. Первый тип (native XML databases) позволяет работать с XML-документами на уровне узлов, но отличается крайне низкой производительностью. Второй тип (XML-enabled databases) позволяет эффективно хранить текст XML-документа в таблице реляционной базы данных, но не позволяет работать с документом на уровне узлов.

Используемая в Системе виртуальная СУБД позволяет хранить XML-документы в таблицах физических СУБД, что обеспечивает эффективность хранения и поиска, а также предоставляет возможность Приложению работать с документом на уровне узлов, поскольку данные текущей записи таблицы автоматически раскрываются в структуру соответствующего ей XML-документа в виде объекта базового класса element. Кроме хранимых в таблице XML-документов можно создавать (нарисовать) производные XML-документы любой сложности, составленные из связанных между собой хранимых документов, изменять их структуру и имена.

Более детально виртуальная СУБД будет описана в следующих статьях, а пока можно посмотреть на показанном ниже скриншоте как атрибуты схемы виртуальной таблицы связывается с соответствующими им полями физической таблицы.

Язык программирования

Система использует язык программирования ULCA (Universal Language for Client Applications), предназначенный для разработки клиентских приложений (как desktop, так и web приложений). Язык ULCA это, своего рода, язык эсперанто для клиентских приложений. Синтаксис языка несколько отличается от синтаксиса, используемого в других объектно-ориентированных языках, хотя Разработчик Системы стремился, где это уместно, придерживаться классики. Семантика синтаксических конструкций, конечно же, сохранена. При создании нового языка Разработчик использовал опыт известного итальянского скульптора и художника. На вопрос, как удается делать столь замечательные статуи, Микеланджело Буонаротти ответил: "Я беру глыбу мрамора и отсекаю все лишнее".

В результате "отсечения" остался следующий состав команд:

• команды определения (par, var, tip...endtip, with...endwith ,text...endtext)

• команды структурного программирования и передачи управления (if...endif, choose...endcase, do...enddo, for...endfor, exit, loop, return, cancel, break, nodefault, try...endtry)

• команды присвоения/слияния (=, )

• комментарии (*, /*...*/)

Несмотря на очевидный минимализм, это мощный язык программирования, имеющий много приятных особенностей. Это касается не только развитых средств IntelliSense, но и техники определения и использования параметров, переменных, системных и API-Функций, обращений к элементам объектов и их подложкам, средств отладки и т.п.

Более детально язык программирования будет описан в одной из следующих статей, а пока можно посмотреть на скриншот отладчика рекурсивной процедуры Recursive, предназначенной для отображения в виде дерева указанного в параметре объекта.

Язык ULCA не является универсальным языком программирования в отличие ,например, от языка С#, который может использоваться для тех же целей, что и ULCA. Хотя ULCA и поддерживает API, но использование его для разработки, например, полноценного графического редактора или игр, не является хорошей идеей. Язык ULCA "заточен" именно под клиентские приложения, он гораздо проще C#, и, как следствие, значительно эффективней.

В Системе реализованы практически все известные на сегодняшний день сколько-либо значимые и перспективные возможности других языков программирования, предназначенных для разработки клиентских приложений. Какое отношение к Системе имеют, например, такие инструменты как ADO, LINQ to XML, LINQ to SQL, XPath, XQuery, XSLT и т.п.? Самое прямое, но ни один из указанных выше инструментов не скопирован, а все их возможности реализованы стандартными средствами языка ULCA и объектной модели Системы. Эти, и многие другие возможности, изначально заложены в Систему, и она не нуждается ни в каких плагинах, надстройках или в специфических языках.

Основные характеристики языка ULC

• Язык высоко уровня. Уровень языка определяется соотношением декларативных и императивных средств языка. В Системе явное предпочтение отдано декларативным средствам. Можно "нарисовать" очень сложный интерфейс пользователя не написав ни строчки программного кода, причем в элементах интерфейса уже "зашит" необходимый для них функционал. Также просто "рисуются" сложные запросы к базе данных и структуры данных. Язык ULCA строго формализован. Именно это позволило так широко использовать декларативное программирование. Преимущество декларативного программирования особенно ощутимо на этапе сопровождения написанного Вами Приложения. Императивные же средства используются для выполнения тех задач, которые трудно формализовать. Как Вы уже, наверное, догадались, Система особенно интересна Разработчикам, которые хорошо владеют понятиями выбранной предметной области и хотят максимально быстро создать Приложение профессионального качества, не отвлекаясь на несущественные детали и особенности языка программирования.

• Жестко типизированный. Система использует следующий набор базовых типов данных:

  • char - строка символов

  • integer - целое число

  • numeric - вещественное число

  • logical - логическое значение

  • date - дата

  • time - время

  • stamp - штамп (дата и время)

  • array - ссылка на массив

  • function – ссылка на функцию

  • object - ссылка на объект

  • variant (undefined) - неопределенное значение

Система выполняет автоматическое преобразование совместимых типов данных в операции присвоения и при приеме/возврате значений аргументов процедуры. Преобразование совместимых типов данных в выражении возможно только явно с помощью функции convert(). Тип данных variant используется как "аэродром подскока" для временного хранения результата, а также для совместимости с внешними данными, тип данных которых явно не поддерживается Системой. Список базовых типов данных является минимальным и универсальным. Он совместим с типами данных всех внешних источников данных и со всеми типами данных, используемых в объектно-ориентированных языках программирования, в том числе и в скриптовых языках, таких как JavaScript и PHP.

• Чисто объектный. Язык ULCA является не объектно-ориентированным, а чисто объектным. В нем используются только объектные конструкции, а Приложение, разработанное с использованием Системы, представляет собой просто набор классов (класс application и все классы, связанные с ним либо непосредственно, либо посредством других классов). При этом класс представляет собой XML-подобный текст (только более компактный) в виде одиночных символов-тэгов, содержащий определение класса для интерпретации универсальным Конструктором объектов и P-код для выполнения Интерпретатором процедур.

• Интерпретируемый. Язык программирования Системы является интерпретируемым, и, как следствие этого, не зависит от платформы, на которой разработанное Приложение будет выполняться. Язык ULCA может быть встроен в любой объектно-ориентированный язык программирования, на котором можно написать Конструктор объектов и Интерпретатор процедур. При этом среда выполнения и все возможности принимаемого языка доступны Интерпретатору. Желательно, но не обязательно, чтобы выбранный язык тоже был интерпретируемым. В качестве таких языков программирования Разработчиком Системы были выбраны Visual FoxPro и JavaScript и соответствующие им фреймворки:

  • Библиотеки среды исполнения Visual FoxPro 9.0 (для разработки и выполнения Приложения в режиме run time)

  • Node.js в качестве web-сервера (для web-версии Приложения)

  • NW (Node Webkit) в качестве среды выполнения desktop-версии Приложения

Почему выбран Visual FoxPro?

 На выбор языка FoxPro повлияло сразу несколько факторов:

•  FoxPro является проприетарным программным продуктом.

• Язык FoxPro является интерпретируемым языком.

• FoxPro прекрасно работает под любой версией Windows, от Windows XP до Windows 11, причем даже на слабом «железе».

• Использование FoxPro является альтернативой использованию C++ в качестве принимающего языка, поскольку эффективность и возможности созданного на основе этих двух языков Приложения практически не отличаются.

• FoxPro — это стабильная Система, поскольку сопровождение было прекращено еще в 2015 году. Может показаться странным, что отсутствие сопровождения рассматривается как положительный фактор. Дело в том, что все старые ошибки FoxPro хорошо известны и легко обходятся, а новые могут появиться только в новых версиях. Появление 64-битовой версии Visual FoxPro 10 Advanced, представленной господином Ченом, вызывает определенный интерес, однако, декомпиляция — это вообще‑то нарушение условий лицензии, даже если Microsoft на это не обращает внимание.

• Движок данных — это визитная карточка FoxPro. До сих пор он остается самым быстрым. Кстати, движок данных FoxPro благополучно вписался и в.NET Framework.

Visual FoxPro оказался идеальной «песочницей» для создания нового языка программирования и интегрированных средств разработки (IDE), а также для написания на языке FoxPro Конструктора объектов и Интерпретатора процедур.

Результаты оказались очень впечатляющими. Если временные характеристики Интерпретатора процедур Системы и родного интерпретатора FoxPro оказались одинаковыми (несмотря на совершенно разные форматы P-кодов), то Конструктор объектов за счет оптимизированного формата хранения классов Системы работает значительно быстрее, чем средства создания объектов с использование таблиц .vcx FoxPro. Таким образом, Система оказалась заметно быстрее Visual FoxPro!

Сложилась очень интересная ситуация. Для работы с Системой нет необходимости покупать лицензию на использование Visual FoxPro, поскольку Система использует только run-time библиотеки, которые могут свободно распространяются вместе с приложением, написанным на языке Visual FoxPro. Таким образом, Система, помимо всего прочего, является полноценным лицензионно чистым инструментом управления базами данных СУБД Visual FoxPro, а Разработчик этой Системы является его законным дистрибутором.

СУБД Visual FoxPro является всего лишь одной из списка доступных в Системе СУБД. Работа с ней ничем не отличается от работы со всеми другими реляционными СУБД. Единственным "пряником" для FoxPro является возможность использовать курсор на таблице, что увеличивает эффективность использования таблиц FoxPro.

Почему выбран JavaScript?

Язык JavaScript - язык программирования, используемый всеми браузерами, поэтому альтернативы этому языку пока просто нет. Есть такое ощущение, что язык JavaScript недолюбливают практически все разработчики. Для этого есть веские основания. Не прекращаются попытки создать новые, более совершенные языки, которые смогли каким то образом облегчить жизнь frontend-разработчикам, например TypeScript, CoffeeScript или Dart. Указанные выше языки объединяет то, что их исходный текст транспилируется в текст на языке JavaScript. Самым известным из них и наиболее часто используемым языком является TypeScript, основная задача которого - обеспечить жесткую типизацию данных языка JavaScript.

Предпринимаются попытки использовать для frontend-разработки язык Python, который успешно используется для backend-разработки. Любителям Python не дает покоя тот факт, что JavaScript освоил "поляну" backend-разработки. Примером такой попытки является проект Brython. Сильной стороной Python является наличие многочисленных библиотек, которые собственно и обеспечивают его функционал. Именно с ними и возникли сложности. Ну и временные характеристики оставляют желать лучшего. Так что, пока JavaScript остается незаменимым

Процедуры, написанные на языке программирования ULCA, компилируется в промежуточный P-код в Системе и уже готовый код передается в браузер для выполнения Интерпретатором, написанным на языке JavaScript. То есть никакого преобразования в формат языка JavaScript не происходит. В этом принципиальное отличие языка ULCA от указанных выше языков. В браузере выполняется оригинальный код языка ULCA, который, как минимум, свободен от тех недостатков, которые не дают покоя frontend-разработчиками, а как максимум, обеспечивает новые возможности, недоступные для языка JavaScript. Такое решение проблем JavaScript является кардинальным и, судя по всему, достаточно эффективным. Кроме того, программный код на языке ULCA защищен от несанкционированного вмешательства, что очень важно для web-приложения.

Интерпретатор и Конструктор объектов, написанные на языке JavaScript являются практически "калькой" с Интерпретатора и Конструктора объектов, реализованный на языке FoxPro. Тем не менее, способ их использования в web-приложении имеет свои особенности.

Производительность web-приложения критически зависит от двух факторов:

• способа обмена данными между web-сервером и браузером

• способ рендеринга изображения на стороне браузера

Эти два фактора тесно связаны между собой. Чтобы эта связь стала понятной, начнем с рендеринга. Когда Вы отсылаете браузеру предварительно сверстанную страницу или фрагмент текста в формате HTML, то создание и обрисовка визуальных элементов страницы осуществляется только средствами браузера без использования скриптов. Другим вариантом является динамическая разметка и обрисовка пустой страницы средствами языка JavaScript. Очевидно, что второй вариант является более гибким, но более затратным.

Насколько второй вариант более затратный подсчитали Разработчики браузера Microsoft Edge. Речь идет о WebUI 2.0. Скупая информация на эту тему появилась совсем недавно. Оказалось, что первый вариант быстрее второго на 42-76 %. Странно только одно - почему этот очевидный факт заметили только сейчас.

Наверное, Вы уже догадались, что для статических визуальных объектов основным способом обмена между web-сервером и браузером являются HTML-текст. Этот текст генерируются Системой из предварительно собранных на основании определений классов форм и всех ее элементов вместе с кодом всех использованных событий и методов. Этот способ похож на использование активных серверных страниц (ASP) с той лишь разницей, что готовый HTML-текст формируется Системой, а не генерируется web-сервером.

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

Если рассматривать Систему только как среду разработки web-приложения, то ее можно сравнить с такими фреймворками, как React.js, Angular.js или Vue.js.

Почему выбраны Nodes.js и NW?

Выбор Node.js в качестве web-сервера и NW (Node Webkit) в качестве среды выполнения desktop-приложения является очевидным, поскольку они являются платформенно независимыми и используют в качестве языка программирования язык JavaScript. Использование единого языка программирования для backend и frontend разработки - это очень хорошая идея.

Основным недостатком указанных выше инструментов является то, что они являются опенсорс-проектами и, как одно из многих неприятных следствий, имеют многочисленные зависимости. Это тот случай, когда: "то, что было, то и полюбила".

Система является pet-проектом и написана одним человеком - Автором этой статьи, что позволило избежать нестыковок между различными инструментами Системы и закончить разработку в приемлемые сроки. Конечно, для pet-проекта эта Система, мягко скажем, крупновата, но работа над ее созданием была очень интересной и, как показалось Разработчику Системы, не такой уж и трудоемкой.

Разработчик Системы имеет большой практический опыт работы с командой программистов при разработке и сопровождении очень крупных проектов, например полнофункциональной банковской системы, и ему хорошо известны все плюсы и минусы коллективной работы. Основной сложностью работы с командой, конечно, является координация работы членов команды, которая может оказаться даже сложнее, чем сама разработка. Это было одной из причин, по которым Разработчик Системы использовал для создания Системы формат pet-проекта.

Если, для создания нового языка программирования и интегрированных средств разработки (IDE) коллективная разработка не эффективна, то для развития, сопровождения и продвижения Системы наличие команды очень даже желательно.

Рабочий вариант Системы должен появиться в первой половине года. Сейчас доступен демонстрационный вариант Системы, который отличается от рабочего небольшим ограничением функционала. Разработчик Системы надеется на обсуждение Системы еще до выхода рабочего варианта. Это поможет ему не только раньше познакомить Вас с Системой, но и внести, если это потребуется, коррективы по Вашим конструктивным замечаниям и предложениям. Очень трудно изменить что-либо принципиальное в работающей Системе. У Вас есть возможность повлиять на ход разработки и даже поучаствовать в ней. У Системы серьезная теоретическая основа и большой потенциал ее практического использования. Есть много нереализованных идей, а также реализованных, но не включенных в Систему. Простота Системы является очень важным ее преимуществом, поэтому при добавлении новой функциональности приходится анализировать, насколько, и для какой категории пользователей она важна, а также, насколько эта функциональность усложнит Систему.

Для того чтобы обсуждение Системы стало предметным, можно скачать установочный файл демо-версии Системы setup.exe по ссылке:

https://disk.yandex.ru/d/_75VHqf_dzcVNg

Данная Система - это классика, точнее classic+. Надеюсь, что со временем значок плюс пропадет, и решения, принятые в Системе, станут стандартом и для других аналогичных Систем. Классика не является чем-то застывшим и неприкасаемым, но следование ей обеспечивает максимальный уровень стабильности и независимости Системы в условиях быстро меняющегося мира.

Автору очень интересно Ваше профессиональное мнение!