1, 2, 3 … Убийца 1С, приди!

Запрос

Если я хочу написать свою систему учета для предприятия, какой несложный стек/фреймворк мне использовать?
Пожелания:
1. Чтобы язык был похож на Visual C, Basic или на Java, Java/Script, несложный.
2. Чтобы формы рисовались в HTML/CSS
3. Чтобы коннектился ко многим СУБД
4. Чтобы был мультплатформенным
5. Чтобы фреймворк был бесплатным или недорогим (100$ максимум), лучше бесплатным
6. Чтобы данные в базе хранились объектно, например есть объект Документ (колонки номер, дата, статус), от него наследуется документы ПриходнаяНакладна и РасходнаяНакладная, у каждого из них свой набор дополнительных колонок к объекту Документ. (входящий номер, входящая дата, контрагент) у приходной (исходящий номре, исходящая дата, контрагент) у расходной.
7. Чтобы был встроенный генератор отчетов, причем в каждой строке могли быть ячейки разной ширины и был вывод в Excel и PDF отчета
8. Чтобы были метаданные и обновление базы клиента через метаданные. т.е. при загрузке новой конфигурации новые поля в базе и таблицы создавались бы, ненужные удалялись бы.
9. Чтобы были расширения клиента, т.е. клиентские доработки, которые создавали бы свои таблицы и поля и коды в базе данных
10. Чтобы можно было бы использовать библиотеки кода

Ответ GPT Luna

Короткий ответ: для разработки своей системы я бы выбрал C# и .NET. Но бесплатного фреймворка, который сразу даст все десять возможностей — особенно метаданные, автоматическое изменение схемы базы и клиентские расширения, — по сути нет. Эти части придётся проектировать как отдельный слой системы.

▎Практичный стек

• Язык: C#.
• Веб-приложение: ASP.NET Core с Razor Pages — формы и страницы пишутся на обычных HTML/CSS, без необходимости делать отдельное JavaScript-приложение. Если нужен более интерактивный интерфейс, можно взять Blazor.
• Работа с БД: Entity Framework Core. Есть провайдеры для PostgreSQL, SQL Server, SQLite и других СУБД; возможности и качество поддержки зависят от конкретного провайдера.
• Миграции схемы: EF Core Migrations или отдельный инструмент, например FluentMigrator. Для пользовательских метаданных потребуется собственная логика миграций.
• Отчёты: можно рассмотреть FastReport .NET, предварительно проверив лицензию и возможности нужной редакции. Для генерации файлов без визуального конструктора — ClosedXML для Excel и отдельную библиотеку для PDF, например QuestPDF; у библиотек проверьте условия лицензии для коммерческого использования.
• База для начала: PostgreSQL. Она бесплатная, кроссплатформенная и хорошо поддерживается в .NET.

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

▎Как это соотносится с вашими требованиями

1–5. Язык, HTML/CSS, кроссплатформенность и стоимость — .NET подходит: C# сравнительно легко освоить, ASP.NET Core работает на Windows и Linux, а основные инструменты бесплатны.

6. Документы с общими и специфичными полями лучше хранить не как «объекты в базе», а обычной реляционной моделью. Например:

Document
  Id, Number, Date, Status, Type

IncomingDocument
  DocumentId, IncomingNumber, IncomingDate, CounterpartyId

OutgoingDocument
  DocumentId, OutgoingNumber, OutgoingDate, CounterpartyId

IncomingDocument и OutgoingDocument связаны с базовой записью Document. Это удобнее для связей, поиска и отчётов, чем пытаться буквально хранить наследование объектов.

7. Отчёты — отдельный компонент, а не встроенная функция ASP.NET Core. Уточните, нужен ли именно визуальный конструктор отчётов или достаточно шаблонов, которые готовит разработчик. Важно: в Excel ширина задаётся для столбца целиком, поэтому ячейки разной ширины в разных строках обычно имитируют объединением ячеек. В PDF такую раскладку сделать проще.

8–9. Метаданные и расширения — это уже разработка собственного механизма, похожего на платформу учётной системы. В нём нужны:
• описание сущностей, полей, форм и отчётов;
• сравнение новой версии метаданных с текущей схемой;
• версионируемые миграции базы;
• подключаемые модули с собственными таблицами, полями и кодом.

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

10. Библиотеки и клиентские модули поддерживаются: код можно разделять на .NET-библиотеки и подключаемые модули. Но загружать сторонние DLL стоит только из доверенных источников — это исполняемый код.

▎Существенная оговорка

Требования «работать со многими СУБД» и «автоматически создавать и удалять таблицы и поля из метаданных» усложняют друг друга. Разные базы имеют разные ограничения и особенности изменения схемы. Если возможность работать с несколькими СУБД не обязательна с первого дня, разумнее начать с одной — например, PostgreSQL — и поддерживать остальные только после проверки сценариев миграции.

Ответ Gemini 3.7 Flash

Ваш список требований практически один в один описывает архитектуру готовой платформы уровня 1С:Предприятие, Odoo или SAP. Если писать такую систему самостоятельно с нуля на обычном языке, реализация пунктов 6, 8 и 9 (наследование сущностей БД, динамические метаданные с автомиграциями и изолированные расширения конфигурации для клиентов) займет годы разработки.

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

Вариант 1. Odoo (Community Edition) — идеальное попадание по функционалу

Если цель — получить работающую систему учета, а не писать собственный компилятор метаданных с нуля, то Odoo закрывает все 10 пунктов из коробки:

  • Лицензия и стоимость: Odoo Community Edition полностью бесплатна (LGPLv3) и мультиплатформенна (Linux, Windows, macOS, Docker).
  • Стек: Сервер на Python (язык очень прост в освоении), фронтенд — HTML / CSS / JavaScript (OWL framework).
  • Объектная модель и наследование (п. 6): Встроена полноценная ORM с несколькими типами наследования (_inherit, _inherits). Например, можно унаследовать базовый документ, добавив новые поля и логику.
  • Метаданные и миграции (п. 8): Вся структура базы генерируется и обновляется на основе декларативных описаний моделей. При обновлении модуля система сама создает таблицы, добавляет колонки и обновляет связи.
  • Расширения клиентов (п. 9): Модульная архитектура позволяет создавать независимые аддоны/плагины. Расширение может переопределять формы, добавлять таблицы и перехватывать методы, не затрагивая ядро.
  • Отчеты (п. 7): Встроенный генератор отчетов на базе QWeb (HTML/CSS) с выводом в PDF (через wkhtmltopdf) и выгрузкой любых представлений в Excel (XLSX). Ячейки разной ширины верстаются обычной разметкой HTML-таблиц.

Вариант 2. Сборка на C# / .NET + Blazor (или Web API + Vue/React)

Если вы хотите полноценно писать собственную систему на языке со строгой типизацией (похожем на Java / C++):

  • Язык и формы: C# (.NET). Формы можно верстать прямо на HTML/CSS с использованием Blazor (компоненты на C# без необходимости писать JS) или сделать классический SPA (Vue.js / React) на фронтенде.
  • СУБД и мультиплатформенность: Работает на Linux, Windows, macOS. Подключается к PostgreSQL, MySQL, MS SQL, SQLite, Oracle через единый интерфейс.
  • Объектное хранение (п. 6): Entity Framework Core (EF Core) поддерживает все паттерны объектного наследования реляционных данных:
  • TPH (Table-per-Hierarchy) — одна таблица со всеми полями и дискриминатором;
  • TPT (Table-per-Type) — базовая таблица с общими полями + дочерние таблицы со специфичными полями (ровно то, что описано в вашем примере);
  • TPC (Table-per-Concrete-Type) — отдельные таблицы под каждый конкретный класс.
  • Генерация отчетов (п. 7):
  • Для Excel: библиотеки ClosedXML, EPPlus или MiniExcel.
  • Для PDF: QuestPDF (декларативная верстка сложных табличных форм с произвольной шириной колонок и строк) или генерация через HTML-шаблоны (Playwright / PuppeteerSharp).
  • Метаданные и расширения (п. 8–9): Реализуются через механизм EF Core Migrations (автоматическое сравнение моделей и базы) либо через динамическую загрузку плагинов (библиотек .dll) с помощью AssemblyLoadContext.

Вариант 3. Сборка на Node.js / TypeScript + NestJS + TypeORM / Prisma

Если предпочтителен стек JavaScript / TypeScript:

  • Стек: TypeScript (дает строгость Java/C#, но сохраняет гибкость JS). Бэкенд на NestJS, фронтенд — любой веб-фреймворк (Vue, Svelte, React) с HTML/CSS.
  • ORM и наследование: TypeORM поддерживает паттерны наследования сущностей (Single Table и Joined Tables).
  • Миграции и метаданные: Встроенные CLI-миграции на базе декораторов сущностей.
  • Отчеты: exceljs для таблиц Excel и puppeteer для рендеринга сложных HTML-таблиц в PDF.

Сравнение подходов

Параметр Odoo Community (Python/JS) C# (.NET Core + EF Core) Node.js (NestJS + TypeORM)
Сложность разработки Низкая (ERP-ядро уже готово) Средняя / Высокая Средняя / Высокая
Готовность метаданных (п. 8) Из коробки (декларативные модели) Требует настройки EF Migrations Требует настройки TypeORM Migrations
Система расширений (п. 9) Встроена штатно Через плагины/MEF (писать самим) Модульная сборка (писать самим)
Формы HTML/CSS (QWeb, OWL) HTML/CSS (Blazor/SPA) HTML/CSS (любой SPA)
Стоимость Бесплатно (Open Source) Бесплатно (Open Source) Бесплатно (Open Source)

Если приоритет — быстро получить готовую архитектуру учета с расширениями и метаданными, лучше всего взять за основу Odoo. Если критично писать ядро самостоятельно на C-подобном языке — связка C# (.NET) + EF Core + QuestPDF/ClosedXML даст наиболее производительный и структурированный результат.

Увы, подобные ответы не вдохновляют. Слишком велика сложность.