I was recently asked by a client how I would go about injecting user information into a service that could be accessed anywhere in the call chain. They did not want have to capture the value at the web layer and pass it to what could be a rather lengthy call stack.

The solution to this is to leverage scoped dependencies in ASP .NET Core which will hold an object for the duration of the request (default). In doing this, we can gather information related to the request and expose it. I also wanted to add an additional twist. I wanted to have two interfaces for the same object, one that enable writing and the other that would enable reading, like so:

The reason for doing this is aimed at being deterministic. What I dont want to support is the ability for common code to accidentally “change” values, for whatever reason. When the injection is made, I want the value to be read only. But, to get the value in there I need to be able to write it, so I segregate the operations into different interfaces.

This may be overkill for your solution but, I want the code to be as obvious in its intent and capabilities – this helps instruct users of this code how it should be used.

Configuring Injection

Our ContextService, as described above, contains only a single property: Username. For this exercise, we will pull the value for this out of the incoming query string (over simplistic I grant you, but it works well enough to show how I am using this).

I am going to define two interfaces which this class implements: IContextReaderService and IConextWriterService, code below:

	public class ContextService : IContextReaderService, IContextWriterService
	{
	public string Username { get; set; }
	}
	public interface IContextReaderService
	{
	string Username { get; }
	}
	public interface IContextWriterService
	{
	string Username { set; }
	}

view raw service.cs hosted with ❤ by GitHub

The tricky part now is, we want the instance of ContextService created with and scoped to the incoming request to be shared between IContextReaderService and IContextWriterService, that is I want the same instance to comeback when I inject a dependency marked with either of these interfaces.

In Startup.cs I need to do the following to achieve this:

	services.AddScoped<ContextServiceFactory>();
	services.AddScoped<IContextReaderService>(p => p.GetService<ContextServiceFactory>().GetCurrentContext());
	services.AddScoped<IContextWriterService>(p => p.GetService<ContextServiceFactory>().GetCurrentContext());

view raw startup.cs hosted with ❤ by GitHub

The secret here is the request scoped ContextServiceFactory which is given as the parameter to AddScoped that allows us to tell .NET Core how to resolve the dependency. This factory is defined very simply as such:

	public class ContextServiceFactory
	{
	private ContextService _currentContext;
	public ContextService GetCurrentContext()
	{
	if (_currentContext == null)
	_currentContext = new ContextService();
	return _currentContext;
	}
	}

view raw factory.cs hosted with ❤ by GitHub

Remember, by default, something added as a scoped dependency is shared throughout the lifetime of the request. So here, we maintain state within the factory to know if it has created an instance of ContextService or not, and if it has, we will return that one. This factory object will get destroyed when the request completed and recreated when a new request is processed.

Hydrating the Context

Now that we have our context split off, we need to hydrate the values, thus we need to inject our IContextWriterService dependency into a section of code that will get hit on each request. You might be tempted to use a global filter, which will work but, the better approach here is custom middleware. Here is what I used:

	// middleware.cs file
	public class HydrateContextMiddleware
	{
	private RequestDelegate _next;
	public HydrateContextMiddleware(RequestDelegate next)
	{
	_next = next;
	}
	public async Task Invoke(HttpContext context, IContextWriterService contextService)
	{
	contextService.Username = context.User.Identity.Name;
	await _next(context);
	}
	}
	// startup.cs Configure method
	app.UseMiddleware<HydrateContextMiddleware>();

view raw middleware.cs hosted with ❤ by GitHub

Because of the way they are used, you can only use constructor injection for singleton scoped dependencies, if you attempt to use a Scoped or Transient scoped dependency in the middleware constructor, it will fail to run.

Fear not, we can use method injection here to inject our dependency as a parameter to the Invoke method which is what ASP .NET Core will look for and execute with each request. Here you can see we have defined a parameter of type IContextWriterService.

Within Invoke perform the steps you wish to take (here we are extracting the username from the name parameter in the Query String, for this example). Once you complete your steps be sure to call the next bit of middleware in sequence (or return a Completed Task to stop the chain).

Using the Reader dependency

Now that we have configured the dependency and hydrated it using middleware we can no reference the IContextReaderService to read the value out. This works in the standard way as you would expect:

	[Route("api/user")]
	[ApiController]
	public class UserController : ControllerBase
	{
	private readonly IContextReaderService _contextService;
	public UserController(IContextReaderService contextService)
	{
	_contextService = contextService;
	}
	[HttpGet]
	public IActionResult GetUser()
	{
	return Ok(_contextService.Username);
	}
	}

view raw controller.cs hosted with ❤ by GitHub

We can inject this dependency wherever we need (though more specifically, wherever we can access the IContextReaderService).

Mutability vs Immutability

The main goal I was trying to illustrate here is to leverage immutability to prevent side effects in code. Because of the interface segregation, a user would be unable to change the given value of the context. This is desirable since it lends to better code.

In general, we want to achieve immutability with objects in our code, this is a core learning from functional programming. By doing this, operations become deterministic and less prone to sporadic and unexplainable failures. While the example presented above is simplistic in nature, in a more complex systems, having assurances that users can only read or write depending on which interface is used allows for better segregation and can yield cleaner and more discernable code.

Hope you enjoyed. More Testing posts to come, I promise.