Как организовать такой роутинг?

Question

[insighter]

Хочу организовать роутинг например такого запроса:
www.myname.ru/services/{dbId}/api/data/get?id=...

Понятно, что после api идет пачка контроллеров и надо бы реализовать централизованную обработку параметра "dbId". По сути это идентификатор схемы данных с которой будут работать контроллеры. С API могут работать разные компании и у каждой данные хранятся в собственной схеме.

[ApiController]
    [Route("services/{dbId}/api/[controller]")]
    public class DataController : ControllerBase
    {
        protected MyDbContext Dbx { get; private set; }

        public DataController(MyDbContext dbx)
        {
            Dbx = dbx;
	    // здесь ничего не известно о структуре запроса, а хочется инициализировать dbx
        }


        [HttpGet]
	[Route("get")]
        public async Task<IActionResult> Get([FromRoute]string dbId, string id)
        {
		...

Как получить dbId в методах контроллера мне понятно, все работает. Но как я могу получить dbId в конструкторе, чтобы прописать его в DbContext.

Может кто даст общий совет, как лучше организовать API, которое работает в подобном изолированном друг от друга контексте (/services/{dbId}/...).

Comments

[Василий Банников]

При регистрации dbcontext в ConfigureServices можно прописать лямбду, которая будет конструировать его.
В ней есть непосредственный доступ к IServiceProvider, из которого можно достать IHttpContextAccessor, через который можно достать HttpContext, из которого можно достать все параметры запроса

[insighter]

Спасибо за совет, но не работает, но это и логично т.к. HttpContext равен null в конструкторе контроллера, конечно он будет не определен и при создании сервиса который создается чуть раньше

services.AddScoped<MyDbContext>(serviceProvider => {
                var httpContext = serviceProvider.GetService<IHttpContextAccessor>()?.HttpContext;
   //  httpContext == null
                return new MyDbContext();
            });

Answer 1

[Илья]

На мой взгляд, это тот случай, когда нужно отказаться от внедрения зависимостей и рулить созданием и временем жизни DbContext самостоятельно. Можно создать фабрику, которая дублирование кода по созданию контекста в зависимости от dbId и ее получать конструктор в местах где это необходимо. Но вот освобождать контекст нужно будет руками.

Comments

[insighter]

Да, сейчас так и делаю - db контекст создается в методе каждого контроллера, потому что только там доступен полный путь запроса.

Мне хотелось сделать, нечто универсальное - место где определяется корневое значение из роута до вызова метода контроллера. Думал это возможно например в конструкторе, но видимо HttpContext создается прямо за шаг до вызова контроллера.

От внедрения зависимостей отказаться не получится, т.к. это не конечный контроллер и он абстрагирован от конечной реализации DbContext, но там есть доступ к хосту приложения и коллекции сервисов, так что создать нужный DbContext не проблема.

Спасибо за ответ

[Илья]

insighter, ок, тогда другой вариант.
Делаем базовый контроллер, в нем поле CurrentDbContext.
Делаем ActionFilter в методе OnActionExecutionAsync из actionContext.ActionArguments пытаемся получить аргумент dbId, если удалось, то заполняем поле CurrentDbContext (actionContext.Controller придется привести к BaseController)
Не забываем написать в BaseController метод Dispose который будет освобождать DbContext если он не null
Добавляем фильтр глобально в методе ConfigureServices