подскажите аналог шаблонов dotnet new или boilr.
Задача — нужно периодически генерировать файлы и каталоги для очередного микросервиса или компонента проекта из его названия и ряда параметров.
Стандартная структура проекта допустим выглядит примерно так:
Хочется на вход передать:
— название продукта и компонента, которое должно подставиться вместо “Product" и "Component" соответственно (т.е. применить замену в названиях файлов и их содержимом)
— опции, которые могут убирать некоторые части, например Api и Worker для данного компонента не нужны, поэтому этих каталогов не будет и в итоговом .sln файле тоже.
Хочется чтобы трансформации описывались в понятной форме.
И хорошо бы иметь возможность писать код с логикой выполнения трансформаций, но это я уже раскатал губу…
Сейчас используем custom шаблоны для “dotnet new”: https://docs.microsoft.com/en-us/dotnet/core/tools/custom-templates
Он не нравится — язык описания подстановок не прост, а уж как приходится приседать если хочется в зависимости от переданных параметров применить трансформации…
boilr не выглядит живым и как я вижу дальше простых подстановок не пошел.
Может кто-то знает более гибкое и удобное решения? Может даже с UI?
Или может кто-то знает хорошие структуры проектов типа приведенного выше?
Может кто-то своим вариантом поделится?
Буду очень благодарен за любые идеи!
Здравствуйте, Keith, Вы писали:
K>Сейчас используем custom шаблоны для “dotnet new”: K>https://docs.microsoft.com/en-us/dotnet/core/tools/custom-templates K>Он не нравится — язык описания подстановок не прост, а уж как приходится приседать если хочется в зависимости от переданных параметров применить трансформации…
Здравствуйте, Keith, Вы писали:
_NN>>Для этого судя по всему есть Post Action и generator.
K>Про возможность подключить скрипты не знал, спасибо. K>Но все равно похоже проще свой консольный проект сделать, чем разбираться с dotnet templating.
Зависит от целей.
У dotnet CLI можно подключать шаблоны через NuGet и даже скачивать автоматически.
Starting with .NET Core 3.0 SDK, the CLI searches for templates in NuGet.org when you invoke the dotnet new command in the following conditions:
If the CLI can’t find a template match when invoking dotnet new, not even partial.
If there’s a newer version of the template available. In this case, the project or artifact is created but the CLI warns you about an updated version of the template.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Keith, Вы писали:
_NN>>>Для этого судя по всему есть Post Action и generator.
K>>Про возможность подключить скрипты не знал, спасибо. K>>Но все равно похоже проще свой консольный проект сделать, чем разбираться с dotnet templating.
_NN>Зависит от целей. _NN>У dotnet CLI можно подключать шаблоны через NuGet и даже скачивать автоматически.
_NN>[q] _NN>Starting with .NET Core 3.0 SDK, the CLI searches for templates in NuGet.org when you invoke the dotnet new command in the following conditions:
_NN> If the CLI can’t find a template match when invoking dotnet new, not even partial. _NN> If there’s a newer version of the template available. In this case, the project or artifact is created but the CLI warns you about an updated version of the template.
Прикольно, но если в большинстве случаев надо один и тот же шаблон и он внутренний для компании,
то не так уж сложно репозиторий один раз клонировать и запустить из него CLI.
Согласен, что свое решение пилить не хочется совсем, но мне кажется оно окупится если надо часто шаблон править.
Здравствуйте, Keith, Вы писали:
K>Прикольно, но если в большинстве случаев надо один и тот же шаблон и он внутренний для компании, K>то не так уж сложно репозиторий один раз клонировать и запустить из него CLI. K>Согласен, что свое решение пилить не хочется совсем, но мне кажется оно окупится если надо часто шаблон править.
K>Может кто-то знает более гибкое и удобное решения? Может даже с UI? K>Или может кто-то знает хорошие структуры проектов типа приведенного выше? K>Может кто-то своим вариантом поделится? K>Буду очень благодарен за любые идеи!
Идея такая — а нафик столько модулей делать ?
Модуль это некая заменяемая единица, смысл вижу если
— есть разные реализации модуля
— есть дистрибутив где разный состав модулей
Например
Product.Component.Core
Product.Component.Core.Repositories
Product.Component.Core.Services
врятли имеют вариации в реализации, почему бы не сделать все в одном модуле.
врятли есть дистрибутив который будет работать без Product.Component.Core.Services или Product.Component.Core.Repositories
Аналогично с Api — оно нужно в отдельном модуле ? Может быть конфигурация без API или где для работы приложения не потребуется загрузить эти модули в память.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Отличный вопрос!
O>Модуль это некая заменяемая единица, смысл вижу если O> — есть разные реализации модуля O> — есть дистрибутив где разный состав модулей O>Например O>Product.Component.Core O>Product.Component.Core.Repositories O>Product.Component.Core.Services O>врятли имеют вариации в реализации, почему бы не сделать все в одном модуле. O>врятли есть дистрибутив который будет работать без Product.Component.Core.Services или Product.Component.Core.Repositories
Редко, но бывает, что реализации разные или что сервисов достаточно без репозиториев.
Но согласен, может проще по дефолту в одну сборку складывать.
Для сборки с тестами зависимости ненужные, если хочется только домен протестировать, например,
но это тоже не критично, можно иметь
Product.Component.Core
и
Product.Component.Core.Test
где тестировать все сразу — и домен и DAL и сервисы...
Просто не по Феншую как-то все в одной куче выглядит,
тем более что разделить на сборки ничего не стоит и выглядит сразу приятней как-то для глаз...
O>Аналогично с Api — оно нужно в отдельном модуле ? Может быть конфигурация без API или где для работы приложения не потребуется загрузить эти модули в память.
Да, контракт без клиента не помню чтоб использовался, поэтому уже объединили.
Вот такая структура получилась, если упростить до предела:
