Passing Parameters To Middleware In ASP.NET Core 2.0

Problem

How do you pass parameters to middleware during its setup in ASP.NET Core?

Solution

In an empty project add a POCO class to hold parameters for the middleware,

public class GreetingOptions
{
public string GreetAt { get; set; }
public string GreetTo { get; set; }
}

Add a middleware,

public class GreetingMiddleware
{
private readonly RequestDelegate next;
private readonly GreetingOptions options;
public GreetingMiddleware(
RequestDelegate next,
GreetingOptions options)
{
this.next = next;
this.options = options;
}
public async Task Invoke(
HttpContext context)
{
var message = $"Good {this.options.GreetAt} {this.options.GreetTo}";
await context.Response.WriteAsync(message);
}
}

Solution A - Instance Type

Add extension method to configure the middleware,

public static IApplicationBuilder UseGreeting(
this IApplicationBuilder app, GreetingOptions options)
{
return app.UseMiddleware<GreetingMiddleware>(options);
}

Configure the middleware,

public void Configure(
IApplicationBuilder app,
IHostingEnvironment env)
{
app.UseGreeting(new GreetingOptions
{
GreetAt = "Morning",
GreetTo = "Tahir"
});
}

Solution B - Function Type

Add extension method to configure the middleware,

public static IApplicationBuilder UseGreeting(
this IApplicationBuilder app, Action<GreetingOptions> configureOptions)
{
var options = new GreetingOptions();
configureOptions(options);
return app.UseMiddleware<GreetingMiddleware>(options);
}

Configure the middleware,

public void Configure(
IApplicationBuilder app,
IHostingEnvironment env)
{
app.UseGreeting(options =>
{
options.GreetAt = "Morning";
options.GreetTo = "Tahir";
});
}

Discussion

I discussed in an earlier post that it is good practice to define middleware in a separate class and add to the pipeline using extension methods. We may also need to pass information to our middleware classes though and I’ve come across two patterns for this when digging into ASP.NET Core source code and other samples online.

These are really straightforward as demonstrated in solution A and B above. We wrap our parameters in a POCO class and create an extension method that takes in either,

POCO instance
Function to call, which in turn sets up the POCO.

Note
That the POCO is passed on to the middleware in its constructor. UseMiddleware() method takes in params object[] for arguments to be passed onto middleware constructor.

Configuring Services

These patterns could also be used for setting up dependency injection the service container. To demonstrate add a service,

public class MessageService : IMessageService
{
private readonly MessageOptions options;
public MessageService(MessageOptions options)
{
this.options = options;
}
public string FormatMessage(string message)
{
// use options
return this.options.Format == MessageFormat.None ? message :
this.options.Format == MessageFormat.Upper ? message.ToUpper() :
message.ToLower();
}
}

Add either of these extension methods to configure services,

// Instance Type
public static IServiceCollection AddMessageFormatter(
this IServiceCollection services, MessageOptions options)
{
return services.AddScoped<IMessageService>(factory =>
{
return new MessageService(options);
});
}
// Function Type
public static IServiceCollection AddMessageFormatter(
this IServiceCollection services, Action<MessageOptions> configureOptions)
{
var options = new MessageOptions();
configureOptions(options);
return services.AddScoped<IMessageService>(factory =>
{
return new MessageService(options);
});
}

Configure services with either of these,

// Instance Type
public void ConfigureServices(
IServiceCollection services)
{
services.AddMessageFormatter(new MessageOptions
{
Format = MessageFormat.Lower
});
}
// Function Type
public void ConfigureServices(
IServiceCollection services)
{
services.AddMessageFormatter(options =>
{
options.Format = MessageFormat.Lower;
});
}

Source Code

GitHub

1 Comment

Join the conversation! Your thoughts help the community grow.

Alex Musumeci6y ago
Thanks for this article, It explains the concept well! One thing I have been trying to understand is the microsoft documentation says that the Explicit Dependencies Principle should be followed and any dependencies should be requested through the middleware constructor, and registered with the DI framework, rather than instantiated with the new keyword. I personally prefer the method you have shown above due to the fact that it is more encapsulated and since we are passing in a Action<Options/Builder/Whatever> we are already tightly coupled to that particular type (at least thats my thinking on it) what are your thoughts?