Перейти до основного вмісту

Як почати

Ця сторінка написана для розробника конфігурації: того, хто створює власний бізнес- застосунок на платформі Kandra. Вам не потрібен — і за замовчуванням у вас його не буде — чекаут вихідного коду самої платформи Kandra. Ваша конфігурація — це власний, самодостатній git-репозиторій, який використовує Kandra.* виключно як NuGet-пакети.

Передумови​

  • .NET SDK, що відповідає net10.0.
  • Доступ до NuGet-фіда Kandra-Erp. Пакети Kandra публікуються у приватному фіді GitHub Packages, а не на nuget.org. Вам потрібен персональний токен доступу GitHub зі скоупом read:packages, встановлений як змінна середовища GITHUB_PACKAGES_TOKEN — попросіть того, хто керує доступом вашої організації до Kandra-Erp, видати вам такий токен. Без нього dotnet restore для згенерованої конфігурації завершиться помилкою.

1. Встановіть інструменти скафолдингу​

dotnet new install Kandra.ConfigTemplate

Опціонально встановіть також інтерактивний майстер (дружніший інтерфейс над тим самим шаблоном — він не виконує жодних файлових операцій сам, лише запитує вас і запускає команду dotnet new kandra-config нижче за вас):

dotnet tool install --global Kandra.ConfigCreateTool

2. Створіть вашу конфігурацію​

dotnet new kandra-config -n Acme --IncludeSqlite

або, якщо встановлено майстер:

kandra-new-config
  • -n <Name> — назва вашої конфігурації. Кожен проєкт у згенерованому рішенні матиме цей префікс (Acme.Domain, Acme.Forms, Acme.WebApi, ...).
  • --IncludeSqlite (за замовчуванням true), --IncludeSqlServer (за замовчуванням false), --IncludePostgres (за замовчуванням false) — оберіть один або кілька провайдерів EF Core. Якщо не обрати жодного, буде виведено попередження, а крок відновлення пакетів пропущено — замість рішення, яке не компілюється.

Це створює порожнє, готове до збірки рішення з 11 проєктів — таку саму форму проєктів, що й KandraWms (власна еталонна конфігурація команди платформи), з видаленими всіма доменно-специфічними частинами, що посилається на платформу Kandra виключно через NuGet PackageReference. У вашому новому репозиторії немає жодного вихідного коду платформи — дивіться Загальна архітектура для детального опису цієї структури з 11 проєктів.

3. Відновлення, збірка, запуск​

cd Acme
dotnet restore
dotnet build Acme.slnx
dotnet run --project src/Acme.WebApi

Спочатку все порожньо — немає жодних Довідників, Документів, Звітів, Регістрів чи Обробників даних — але застосунок повністю працездатний одразу після створення: ви побачите робочий екран входу та порожнє меню навігації.

4. Додайте вашу першу сутність — використовуйте вбудовані навички​

Ваш згенерований репозиторій постачається з власною папкою .claude/skills/ (по одній навичці на вид сутності: create-dictionary, create-document, create-register, create-report, create-data-processor, create-constant, а також create-handler, create-local-handler, post-to-accounting, add-account-subconto-field, add-interface-node, create-print-form, convert-dictionary-to-hierarchical) та власним файлом CLAUDE.md, написаним спеціально для роботи саме з цим згенерованим репозиторієм — це інший файл, ніж власний CLAUDE.md команди платформи. Якщо ви використовуєте Claude Code, надавайте перевагу викликам цих навичок, а не ручному відтворенню форми сутності з нуля — це явна рекомендація, з якою постачається шаблон, а не просто порада цього сайту. Посібники «Створення...» в цьому розділі дають концептуальний контекст, який передбачає кожна навичка; саму механічну роботу у вашому репозиторії виконує навичка.

Запуск тестів​

dotnet test Acme.slnx

За замовчуванням постачається один smoke-тест, що підтверджує, що вже готові міграції застосовуються без помилок до SQLite в пам'яті — дивіться Тестування.

Міграції бази даних​

Дивіться Міграції бази даних — ваш згенерований репозиторій вже містить маніфест, потрібний kandra-migrate, тож саме цей інструмент варто використовувати; прямий виклик dotnet ef для кожного провайдера — це резервний варіант, якщо інструмент ще не встановлено у вашому середовищі.

Дослідження власної еталонної конфігурації команди платформи (опціонально)​

Усе вище — самодостатнє: вам ніколи не потрібен вихідний код самої платформи Kandra, щоб створити конфігурацію. Робочі приклади навичок навмисно повторно використовують реальні назви сутностей з попередньо створеної конфігурації (кожна навичка одразу про це попереджає), а не вигаданий загальний приклад — саме для того, щоб ви дивилися на перевірений робочий код навіть без такого доступу. Якщо ви хочете піти далі й прочитати вихідний код власної еталонної конфігурації команди платформи напряму, це означає доступ до їхнього внутрішнього монорепозиторію — окремий від фіда пакетів вище, і те, що більшості розробників конфігурацій не знадобиться.

Куди йти далі​