Ребят, нужен совет по архитектуре webapi приложения. У меня есть

Question

Ребят, нужен совет по архитектуре webapi приложения. У меня есть

куча сервисных классов с бизнес-логикой, в каждый из этих классов в конструкторе заинжекчен самописный ServiceFabric - фабрика сервисных классов, который позволяет получать нужные им зависимости. По сути ServiceFabric это обёртка над стандартным IServiceScope, только с логикой переключения между двумя БД (RW и RO): он не просто инстацирует сервисный класс, а ещё указывает ему, с какой БД тому работать. Это делается, грубо говоря, через булевскую переменную внутри самого ServiceFabric, который передаётся в инстанцируемый класс. Более того, важный момент: эта булевская переменная должна прокидываться дальше по цепочке вызовов.
Т.е. Service1 через свой ServiceFabric инстанцирует Service2, указывав ему работать с RW базой. Service2, инстанцируя нужные ему Service3 и Service4 автоматески передаёт переменную им, так что они тоже невольно работают с RW. Надеюсь понятно объяснил.
Так вот, пока я пользовался Autofac, это было реализовано через TypedParameter - я на этапе резолва создавал экземпляр ServiceFabric и инжектил его. Но сейчас отказываюсь от Autofac, хочу остаться только со стандартным DI от Microsoft, но в нём, как оказалось, нету аналога передачи типизированных параметров.
Гуглю решения - на стэковерфлоу советуют использовать паттерт Options, т.к. по сути во свои сервисные классы добавить отдельный метод инициализации нужным мне экземпляром ServiceFabric. Но вариант мне не нравится по ряду причин. Можете посоветовать другие?

#backend #dot #programming #russian

0

22.04.2021