Що таке Kandra
Kandra — це рушій для ERP/бізнес-застосунків на .NET (C# / EF Core / Blazor / Avalonia). Він переосмислює доменні абстракції, на яких побудований успіх 1C:Enterprise та Odoo — Документи, Довідники, Регістри, Звіти — використовуючи сучасні ідіоми C# та інструментарій, орієнтований на роботу зі ШІ, замість власної скриптової мови чи Python ORM, накладеного на загальний веб-фреймворк.
Якщо ви конфігурували 1C або розробляли модулі для Odoo, поняття тут будуть знайомими. Якщо ні — уявіть Kandra як фреймворк, у якому форма бізнес-об'єкта (чи проводить він транзакції? чи зберігає довідкові дані? чи є він звітом лише для читання?) визначає фіксований набір частин, які ви реалізуєте, а решту генерує фреймворк — REST-контролери, DI-конфігурацію клієнта, конфігурацію EF Core, а для кількох видів сутностей — і сам UI на Blazor.
Дві речі в цьому сімействі репозиторіїв
- Kandra (платформа) — багаторазовий рушій, який використовується як набір бібліотек. Саме на нього ви посилаєтесь при створенні нової конфігурації; форкати його не потрібно.
- KandraWms («Kandra WMS») — перша еталонна конфігурація, побудована на платформі: реальний домен управління складом плюс підсистема проведень з планом рахунків. Вона існує, щоб довести, що рушій працює для реального домену «з початку до кінця», і саме на неї постійно посилаються практичні посібники цього сайту як на робочий приклад.
Конфігурація, у термінах Kandra, — це ваш власний проєкт у формі KandraWms: набір
Довідників/Документів/Регістрів/Звітів, які моделюють ваш бізнес-домен, побудований шляхом
посилання на бібліотеки платформи Kandra так само, як це робить KandraWms. На практиці ви не
створюєте цю форму вручну — ви створюєте її шаблоном dotnet new, який генерує порожній,
готовий до збірки проєкт, що посилається на платформу виключно через пакети NuGet, без
потреби у вихідному коді платформи. Дивіться Як почати.
Система типів сутностей — базова абстракція
Кожен бізнес-об'єкт, який ви створюєте, належить до одного з семи видів, кожен із фіксованим профілем можливостей:
| Вид | Проводиться? | Має UI/форму? | Типове застосування |
|---|---|---|---|
| Документ (Document) | Так | Так | Транзакційні записи — видаткові накладні, рахунки, переміщення. Записує регістри та проведення лише всередині OnSubmitAsync. |
| Довідник (Dictionary) | Ні | Так | Довідкові/майстер-дані — товари, склади, контрагенти. Опціональна ієрархія. |
| Звіт (Report) | Ні | Так (згенерований) | Параметризовані запити лише для читання над регістрами/документами. |
| Обробник даних (DataProcessor) | Ні | Так (тимчасовий) | Форма пакетної операції, яка сама не зберігається. |
| Регістр (Register) | — | Ні | Аналітичне сховище (залишки, обороти, інформаційні записи), яке записується лише поведінками документів. |
| Константа (Constant) | Ні | Лише адмін-UI | Одне скалярне значення конфігурації. |
| Перелік (Enum) | — | Ні | Звичайний перелік C#, який використовується як будь-який інший .NET enum, але інтегрований у згенерований UI/шар друку. |
Кожен вид із власною формою (Документ/Довідник/Звіт/Обробник даних) будується з однакових чотирьох частин, розділених на дві площини — лише-сервер та спільну клієнт+сервер:
- Сутність
*Base— чиста модель EF Core. Без атрибутів UI чи авторизації. *Dto— насичений атрибутами контракт, який читають генератори для створення контролерів, DI-конфігурації клієнта та згенерованого UI.*Behavior— хуки життєвого циклу (OnNewAsync,OnBeforeSaveAsync,OnSubmitAsync, ...).*Validator— спільна валідація клієнт+сервер, обов'язкова, навіть якщо вона просто делегує до базової реалізації.
Ви будете створювати всі чотири частини, у такій формі, майже для всього, що додаєте. Посібники Створення довідника та Створення документа показують це на конкретному прикладі.
Чому генератори, а не скриптова мова
І 1C, і Odoo вирішують проблему «не повторюй себе між формою/API/зберіганням» за допомогою
динамічного шару метаданих часу виконання або скриптової мови. Kandra вирішує ту саму проблему
за допомогою генераторів коду Roslyn: ви пишете строго типізований *Dto на C# з
атрибутами, а генератор створює справжній C# — справжній контролер, справжню DI-реєстрацію,
справжню конфігурацію EF Core — у папку Generated.Net/, яку можна читати (але ніколи не
можна редагувати вручну). Це означає:
- Повне IntelliSense та перевірку типів на етапі компіляції для згенерованого коду, оскільки він є перевіреним компільованим C#, а не скриптом, що інтерпретується під час виконання.
- Відсутність окремого кроку «перекомпілювати шар метаданих» — звичайний
dotnet buildперегенеровує все. - ШІ-асистенти для написання коду (частково для цього й існує ця документація) можуть читати згенерований вивід напряму, щоб зрозуміти, що саме створює конкретний атрибут Dto, замість того, щоб симулювати рантайм скриптової мови.
Куди йти далі
- Як почати — створення, збірка та запуск вашої власної конфігурації.
- Загальна архітектура — як частини вище складаються у працюючу систему (проєкти, DI, конвеєр обробки запитів).
- Далі оберіть потрібний вид сутності: Довідник, Регістр, Документ, Звіт, Обробник даних або Константа.