Разделение контейнера зависимостей в ASP.NET Core

Разработчики AspNet Core (здесь и далее речь идёт об AspNet актуальных версий: 6 и 7, но может быть применимо и к более ранним версиям) хорошо знают, что механизм Dependency Injection встроен в этот фреймворк изначально и пронизывает его насквозь. И это здорово упрощает работу с зависимостями и сразу вводит разработку в идеологически правильное русло. Более того, в состав самого AspNet входит вполне приличный дефолтный DI-контейнер разработки Microsoft, что позволяет отказаться от использования сторонних решений. Во всяком случае, при отсутствии совсем уж специфичных требований.

Проблема (или, скорее, особенность) ServiceProvider

Главная особенность встроенного ServiceProvider - он единый и глобальный. Да, в нём есть скоупы, но они используются только для управления временем жизни создаваемы зависимостей, например "в рамках обработки конкретного HTTP-запроса". Но, например, если вам нужно в какую-то часть HTTP-конвейера передать другой вариант настроек базовых служб (например, используя методы AddXXX), то у вас проблема.

У меня есть веб-приложение, работающее с базой данных через такой незамысловатый интерфейс:

public interface IDbProvider
{
	DbConnection CreateConnection();
}

Я регистрирую конкретную реализацию провайдера на этапе настройки конвейера, компоненты приложения получают его из DI-контейнера, всё работает как по нотам. Но тут у меня появилась задача добавить копию функционала приложения, например в URI /test, которое должно работать со своей базой данных, отдельной от основного приложения. Задача осложнялась тем, что та же база данных использовалась в обработчиках метода AddAuthentication(). Иными словами, нужно было обособить часть HTTP-конвейера, передав ему свои зависимости, в том числе системные, наподобие аутентификации.

Вроде бы можно добавить второе приложение Kestrel со своими настройками и не заморачиваться. На практике же дело осложнялось тем, что пользователями приложения были разные, иногда совсем небольшие организации, с очень маленькой ИТ-службой или вообще с единственным приходящим админом. Настраивать новый инстанс на другом порту или реверс-прокси просто некому. Решение должно быть максимально простым: запустил MSI с новой версией приложения, нажал next-next-next и всё, никаких лишних телодвижений и настроек.

Поиск решения

Всемирный поисковый разум не дал особых результатов, нашлась только одна статья, которая более-менее описывала мою задачу и возможный путь её решения. Конечно, отсутствие статей говорит о том, что проблема редкая и, следовательно, мало кому интересная. И что наверняка проще сделать отдельное приложение. Но тут уже победило природное любопытство.

Сначала я решил взять за образец решение из упомянутой статьи. Но оно изначально было с душком: финты ушами с копированием контейнера вроде бы работали, но где-то лезли маленькие глюки и вообще всё это выглядело совсем не comme il faut. Помыкавшись с кодом, я уже хотел бросить затею, но тут всплыли два воспоминания, случайно осевших на чердаке после чтения документации на DI-контейнер Autofac, который когда-то использовался для другого проекта.

Первое заключалось в том, что AspNet позволяет заменить штатный DI-контейнер на любой другой совместимый. Autofac как раз один из таких. Парой строчек кода он легко встраивается в AspNet, полностью и бесшовно заменяя встроенный ServiceProvider.

Второй важной особенностью этого DI-контейнера является гораздо более мощная поддержка дочерних скоупов, включая возможность дорегистрировать в них зависимости, и даже переопределять зависимости, зарегистрированные ранее в родительских скоупах. Детали, как всегда, хорошо документированы.

Собираем паззл воедино

Двух перечисленных особенностей Autofac и ранее упомянутой статьи оказалось достаточно для решения поставленной задачи.

После некоторых упражнений рождается метод-расширение MapPartition(), являющийся аналогом штатного Map() с единственным отличием: часть конвейера, выполняющаяся внутри обработчика MapPartition(), выполняется в отдельном дочернем скоупе DI-контейнера с возможность добавления или переопределения зависимостей.

Полный текст метода-расширения:

public static IApplicationBuilder MapPartition(this IApplicationBuilder app, PathString pathMatch,
	bool preserveMatchedPathSegment, Action<IServiceCollection, IServiceProvider> configureServices, Action<IApplicationBuilder> configuration)
{
	// 1. Extract parent scope from the existing container
	var parentScope = app.ApplicationServices.GetRequiredService<ILifetimeScope>();
		
	// 2. Сreate child Autofac ILifetimeScope
	var childScopeFactory = new AutofacChildLifetimeScopeServiceProviderFactory(parentScope);

	// 3. Register new services
	var services = new ServiceCollection();
	serviceConfiguration(services, app.ApplicationServices);
	var serviceAdapter = childScopeFactory.CreateBuilder(services);

	// 4. Сreate a new pipeline branch
	var branchBuilder = app.New();
	// replace ServiceProvider in the to the scoped one
	branchBuilder.ApplicationServices = childScopeFactory.CreateServiceProvider(serviceAdapter);
	branchBuilder.Use(
		async (c, next) =>
		{
			c.RequestServices = branchBuilder.ApplicationServices;
			await next();
		});
	configuration(branchBuilder);
	var branch = branchBuilder.Build();

	// 5. Link the new branch to the original pipeline
	var options = new MapOptions
	{
		Branch = branch,
		PathMatch = pathMatch,
		PreserveMatchedPathSegment = preserveMatchedPathSegment
	};
	return app.Use(next => new MapMiddleware(next, options).Invoke);
}

По комментариям уже понятно, что делает метод:

1. Извлекает ссылку на текущий скоуп Autofac из контейнера.

2. Создаёт новый дочерний скоуп Autofac.

3. Регистрирует новые зависимости в рамках созданного скоупа.

4. Создаёт новую ветку конвейера, обёрнутую в middleware, заменяющий родительский скоуп на дочерний в свойствах HttpContext.

5. Прикрепляет созданную ветку конвейера к основной, используя штатный MapMiddleware.

Использование созданного метода:

internal static class Program
{
	private static void ConfigureWebHost(IWebHostBuilder builder)
	{
		// add global services to the container
		builder.ConfigureServices(
			services =>
			{
				services.AddHttpContextAccessor();
				services.AddControllersWithViews();
				// register main database
				services.AddSingleton<IDbProvider, MainDbProvider>();
			});
			
		builder.Configure(
			(context, app) =>
			{
				app.MapPartition("/test", false,
					// register test database
					(services, parentServices) => services.AddSingleton<IDbProvider, TestDbProvider>(),
					appPart => 
					{
						// test partition
						appPart.UseRouting();
						appPart.UseEndpoints(endpoints =>
						{
							endpoints.MapControllerRoute(
								name: "default",
								pattern: "{controller=Home}/{action=Index}/{id?}");
						});
					});

				// main partition
				app.UseRouting();
				app.UseEndpoints(endpoints =>
				{
					endpoints.MapControllerRoute(
						name: "default",
						pattern: "{controller=Home}/{action=Index}/{id?}");
				});
			});
	}

	public static void Main(string[] args)
	{
		var builder = Host.CreateDefaultBuilder(args);
		// replace default ServiceProvider
		builder.UseServiceProviderFactory(new AutofacServiceProviderFactory());
		builder.ConfigureWebHostDefaults(ConfigureWebHost);
		var host = builder.Build();
		host.Run();
	}
}

В примере выше вызов MapPartition("/test", false, ...) заворачивает все вызовы с префиксом пути /test в отдельную ветку конвейера. Префикс при этом удаляется, что позволяет использовать все те же самые контроллеры приложения, но уже с другим набором зависимостей благодаря выделенному дочернему скоупу Autofac.

Заключение

Найденное решение по разделению DI-контейнера оказалось вполне работоспособным, оно уже работает год в реальных проектах без всяких проблем.