Нет возможности поменять формат
Это файл для интеграции со сторонним сервисом, которому нужен их же формат: "# ##0,00\ _₽", который они в свой шаблон и добавили, а мы в шаблон пишем свои значения
Ali-Muhammad Zakarayayev, vertical slices, чтобы код можно было вертикально прочитать спокойно, 1 операция - 1 обработчик команды, всё просто. Всегда знаешь, что конкретный usecase у тебя отвечает за 1 определенный бизнес-процесс, а не так, что у тебя в сервисе может находиться сразу 20 этих самих процессов.
GlazOtca, Одно дело, если бы мне клиент выдавал 404, что appsettings.development.json не найден, а другое, что он даже и не пытается его с сервера взять
mxelgin, Никто не запрещает вам ввести свою Environment переменную, либо принять как факт, что если запущено в Docker'e - Production, иначе - Development/Staging. Напишите в ТГ @ow_dafuq, так будет проще показать на примерах :)
mxelgin, , вам нужен метод с bool аргументом в конце. А launchSettings.json - сам за себя говорит, отвечает за запуск приложения, но никак не настройки внутри приложения. Если кратко - можете написать метод(-расширение), в который передадите IServiceCollection, IConfiguration, IHostEnvironment, внутри которого, если вы находитесь, например, в Development'e, то подцепляете дополнительно .Development.json конфиг.
mxelgin, Не понял, как он будет тащить строку "по дефолту", если у вас в 2-х конфигах будут разные строки подключения и меняться они будут сами, в зависимости от среды? В этом и смысл разделения конфигов таким образом, что он будет сам решать, какой конфиг с какой строкой подключения ему взять
Имхо, но проще будет сделать 2 конфига, а потом, в зависимости от Environment'a, подцеплять нужный. Например: appsettings.Production.json и appsettings.Development.json.
Петр, Просто смотрю пример в яндекс апи, там точно так же выдается API ключ, который может жить хоть 1000 лет. Просто какие могут быть подводные камни при таком подходе, как я выше описал?
Петр, Сейчас сделано так: самописный сервис для выдачи JWT, в нем же регистрация, авторизация по refreshToken'y или паролю, изменение пользователя, управление ролями. Но мне не очень нравится JWT, на сколько будет адекватно сделать свою авторизацию на статичных токенах (которые не надо обновлять), хранить их в Redis, так же этот токен пересылать от сервиса к сервису в заголовке, а на сервисе будет своя схема авторизации, которая будет делать обычный get запрос к сервису авторизации с этим токеном, а он будет отдавать все claims'ы, которые есть у этого токена. Так же туда можно будет добавить и свой "client-id", чтобы понимать какому приложению какой токен относится. На сколько это будет выглядеть адекватно?
Петр, Да никаких. Вопрос в целом про то, что делать с авторизацией, как передавать токен из сервиса в сервис, как быть с ролью доступа к списку пользователей и прочее.
MVV, Так, немного момент упустили, наверно. Пока решили оставить всё как было, но вопрос поднялся снова. В общем, объясню еще раз, от EF мы уходить не собираемся, его возможностей нам с головой хватает. В Application слое у нас была зависимость от только UnitOfWork, то есть, в каком-нибудь handler'e медиатра у нас в конструкторе может быть только 2 зависимости: логгер и сам uow. Таким образом, если я убираю инфраструктурный слой, то остается 3: Host, Domain, Application. В Domain у нас нет сервисов(!!!), весь бизнес лежит в Application, потому что у нас не DDD, доменных сервисов нет и быть не может. Собственно и есть вопрос, нужен ли UoW, когда у нас указывает всё на то, что он не нужен и избыточен, когда можно напрямую работать с EF без лишних абстракций.
Ну, как раз таки к EF привязаться и хотелось. Всё делаем на нем, его возможностей нам с головой хватает. В Application не используется ни DataSet, не DbContext, только IUnitOfWork интерфейс и всё.