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 интерфейс и всё.
Василий Банников, ну вот это уже звучит как аргумент :)
Спасибо! Будем слегка смещать UoF в сторону сервисов, которые реализовать будем в Infrastructure, когда это возможно. Можете оформить как ответ, в целом это решает мою головную боль :D
Роман, А еще можно с апи отдавать время жизни токена и проверять время жизни без запроса на сервер, проверил время жизни - подходит к концу или кончилось - обновил - послал запрос дальше, но уже с новым токеном