Почему и как написать убийцу 1С

Думаю, сразу нужно разъяснить, особенно для тех, кто не сталкивался с 1С, что она состоит из двух частей. Есть платформа 1С, на которой можно разрабатывать тиражирумые приложения баз данных, или конфигурации. И есть сами коммерческие конфигурации, из-за плохой маркетинговой политики в основном от самой фирмы 1С.

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

Но платформа 1С стоит минимум 13.000 рублей, это порядка 200$. Поэтому, к сожалению, на ней нельзя разрабатывать мелкие приложения. 1С не придумала создать магазин приложений, вроде Play Market, куда можно было бы размещать простые недорогие конфигурации. Единственный вариант сделать конфигурацию ценой 1-5000 рублей — это ввязаться в 1С: Совместимо. Но это весьма затратный и бюрократический квест. После прохождения которого ваша конфигурация появится в прайсе 1С.

Понятно, что этот путь не подходит для микро и pet-приложений.

Поэтому возник вопрос — а как разрабатывать подобные приложения так же быстро и эффективно, как в 1С, какой набор инструментов собрать, какими качествами должна обладать среда разработки. Попробуем разобраться в этом вопросе.

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

Кроме того, 1С имеет очень плохие отношения со своими программистами-разработчиками. Создание альтернативной open-source платформы позволило бы сделать позитивное сообщество разработчиков.

Абстракция над реляционной СУБД

1С работает не с таблицами, а с некоторыми абстракциями над таблицами.

Тем не менее, можно строить SQL-подобные запросы по этим абстракциям, как по обычным таблицам.

Есть справочники и документы, которые состоят из таблицы объектов. И каждый объект может иметь несколько таблиц табличных частей.

Например, у объекта Накладная может быть таблица самих накладных, в которой содержится список накладных, и таблица Товары, в которой для каждой накладной содержится список ее товаров с количеством, ценой и суммой.

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

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

В принципе, такая абстракция не обязательна, на первых этапах ею можно пренебречь.

Поддержка различных СУБД и сервер приложений

1С поддерживает несколько типов СУБД: MS Sql, Postgree, IBM DB2 и даже собственный файловый вариант базы данных.

Альтернативная платформа может тоже поддерживать различные СУБД, за счет того, что работа с базой данных должна быть максимально стандартизирована и формализована. Чтобы код одинаково работал на разных базах данных.

Также нужно определиться, что будет выступать сервером приложений. Обычно это какой-нибудь движок сайта, Apache или IIS, который будет выполнять код на компьютере с базой данных. Или сама база данных, если она умеет выполнять код, отличный от SQL.

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

Составной тип полей

В 1С поле может ссылаться на объекты разных типов. Это упрощает формализацию предметной области. Но альтернатива реализуется довольно просто.

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

Метаданные и тиражируемость

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

Это позволяет обновлять конфигурации пользователей или создавать базу с нуля по заданной структуре.

В принципе, на первых этапах можно обойтись без метаданных, просто реализовав скрипт по тиражированию базы данных. Чтобы структура базы данных нового релиза выгружалась в XML, а у пользователя старая структура базы данных конвертировалась под эту структуру.

Также наличие метаданных позволяет автоматически генерировать нужное поведение данных в формах. Но это тоже не особо критично.

Простота разработки форм

В большинстве IDE и языка программирование для разработки форм используется ООП, где над базовым классом формы создается класс новой формы и для каждого элемента формы создается своё поле этого класса. Но такой подход не универсален, т.к. не подходит для динамически создаваемых форм, где можно создавать множество элементов управления в зависимости от потребностей приложения.

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

Вот как выглядит форма записи дневника, например:

При этом нет нужды точно позиционировать элементы управления, для их составления используется порядок и группировка элементов управления в их последовательности. Это выглядит так:

Чтобы максимально упростить разработку форм и альтернативную платформу, все элементы формы должны создаваться программно.

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

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

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

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

Клиент-серверное выполнение

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

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

Распределение клиентского и серверного кода будет в руках программиста — что выполнять на клиенте, что на сервере.

Некоторые альтернативные платформы, как Фузина, вообще, весь код выполняют на сервере, отрисовывая формы по принципу Remote Desktop. Но тем не менее, предоставляется возможность выполнять код на клиенте, когда требуется работа с клиентским оборудованием.

Коллекции в памяти

Должна быть возможность работы с простыми коллекциями — структурами, списками, массивами. Это очень востребовано в обработке данных.

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

Простота кода

Код должен быть простым:

1. Простой синтаксис, а-ля Питон или JS
2. Отсутствие типизации
3. Runtime выполнение, а не компиляция.

Отчеты и печатные формы

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

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

Это позволяет создавать довольно сложные печатные формы:

И выводить достаточно гибкие отчеты:

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

В принципе, использование строк с разной шириной колонок не обязательно, можно использовать стандартную сетку, как в Excel, тогда печатные будут менее гибкие и придется делать мелкую сетку, чтобы объединять нужные ячейки:

Также желательно, чтобы можно было в печатном документе выделять, чтобы копировать нужные участки из макета в результирующий отчет, вот пример именованных секций (имена слева от таблицы-сетки):

Простота установки IDE и совместимость конфигураций

Я имел опыт установки Microsoft Visual Studio, где нужно установить множество галочек, выбрать необходимые библиотеки. Мне был нужен только C#, но этот квест показался достаточно сложным.

Если для платформы использовать MVC, то, наверное, нужен специальный инсталлятор, который за пользователя установит эту оболочку с нужными опциями.

Как-то через пару лет я открыл старый проект C#, открыл его в заново установленной Visual Studio и он отказался компилироваться. Причина была в том, что на компьютере не было нужной версии Net Framework. В 1С такого не бывает — там полная обратная совместимость.

Резюмируя:

1. IDE должна устанавливаться с минимумом опций.
2. Старые конфигурации должны поддерживаться в новых версиях IDE.
3. Необходимые базы данных и сервера приложений тоже должны ставиться из дистрибутива. Можно использовать базы данных на хостингах в интернете, чтобы не разворачивать их самому.

Список для разработки

Резюмируя описанное, для разработки альтернативной платформы понадобится:

1. Выбрать одно СУБД для начала, например MySQL. Базы на нем можно даже не устанавливать, а использовать готовые на хостинге.
2. Выбрать сервер приложений
3. Выбрать язык и его среду-исполнителя. Причем на сервере и на клиенте. Желательно, чтобы это был простой, динамически интерпретируемый нетипизированный язык на сервере и клиенте.
4. Выбрать библиотеку для динамического отображения форм. Включая отображение записи, набора записей в базе и набора записей в памяти.
5. Написать скрипт по тиражированию структуры БД.

Пример написания конфигурации на альтернативной платформе

Рассмотрим небольшой фрагмент реализации приложения на альтернативной конфигурации. Фрагмент будет касаться оформления заказа от покупателя.

(будет реализовано позже)