Search  
Always will be ready notify the world about expectations as easy as possible: job change page
Jul 11

.NET | Working with options pattern

.NET | Working with options pattern
Author:
Source:
Views:
1828

Another way to read data from the configuration data

Options pattern introduction

Options pattern is a flexible configuration data management way that enables us to use strongly typed configurations. It uses classes to bind groups of related configurations. We can inject these classes via dependency injection with IOptions<T> to include only the part that we need.

This pattern satisfies two main and important software engineering principles.

  • Encapsulation: these classes only depend on the configuration settings that they use.
  • Separation of Concerns: Settings for different parts of the app aren’t depending on one another.

Why use IOptions pattern

For example, let’s assume that we have some configuration settings in the appSettings.json

{
  ...

  "Jwt": {
    "Issuer": "thisisyourissuers",
    "SigningKey": "thiskeyisveryhardtobreak",
    "IsValidateLifetime": true
  },

  ...
}

For reading the Issuer, we can directly access its value by using the classic IConfiguration instance, which is already automatically registered into the dependency injection container since ASP.NET Core 2.0.

We can directly use it through:

public class HomeController
{
   public HomeController(IConfiguration configuration)
   {
      // Use IConfiguration instance
      var issuer = configuration["Jwt:Issuer"]   }
}

This way will become extremely hard to maintain when the structure of the configuration goes diverse with deeply nested sections.

Instead, we can create a “strongly-typed” class to sections in the configuration to separate the concerns and make it easy to access and maintain.

Back in our example, our strongly typed class for the Jwt section can be as below:

public class JwtOptions
{
  public string Issue {get; set;}
  public string SigningKey {get; set;}
  public bool IsValidateLifetime {get; set;}
}

We need to ensure that the property names and types must match the key names and values exactly in the configuration file.

The next step is to register this class into the dependency injection container so that we can use it in other areas, like services or controllers.

One approach is to use the bind method. We can manually create an instance of this class and bind it to the configuration section of the JSON file.

# Startup.ConfigureServices() Method #

JwtOptions jwtOptions = new();
Configuration.GetSection("Jwt").Bind(jwtOptions);
services.AddSingleton(jwtOptions);

Alternatively, we can use them Get() to avoid using the “new” keyword.

JwtOptions jwtOptions = Configuration.GetSection("Jwt").Get<JwtOptions>();
services.AddSingleton(mailFeature);

To use the instance in our logic, we can just inject the class into the constructor of the component where it will be used.

public class HomeController : ControllerBase
{
    private readonly JwtOptions jwtOptions;

    public JwtController(JwtOptions jwtOptions)
    {
        this.jwtOptions = jwtOptions;
    }

Although this approach works, the drawback is also obvious that we still have to explicitly create an instance by ourselves while using the dependency injection.

Here is where the IOptions pattern comes into play.

How to use IOptions pattern

The above logic can be written as:

// Startup.cs
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        // Some code...

        services.Configure<JwtOptions>(Configuration.GetSection(nameof(JwtOptions)));

        // Some other code....
    }
}

Instead of using Bind or Get methods, we can achieve this by using GetSection to get a configuration sub-section with the specified key.

In this way, we can easily achieve the same result by writing easier and less code.

The IOptions interface is part of the Microsoft.Extensions.Options namespace, which is available implicitly in the .NET Core package.

To get the TOptions instance in our controller or services, there are three interfaces provided by this package.

  • IOptions
  • IOptionsSnapshot
  • IOptionsMonitor

They can be used in the same way but for different scenarios, like:

public class JwtController : ControllerBase
{
    private readonly JwtOptions jwtOptions;

    public JwtController(IOptions<JwtOption> jwtOptions)
    {
        this.jwt = jwtOptions.Value;
    }
}

When to use which

IOptions:

  • registered as a singleton service, hence can be injected into any service.
  • configuration changes cannot be re-read once instantiated, since it’s a singleton.
  • Doesn’t support “named” options.

IOptionsSnapshot:

  • registered a scoped service, hence cannot be used inside the singleton service.
  • enable reload when configuration changed.
  • Supports “named” options.

IOptionsMonitor:

  • registered as a singleton service, hence can be injected into any service.
  • enable reload when configuration changed.
  • Supports “named” options.

Check here for understanding what is named option:

Similar
Feb 7, 2023
Author: Alex Maher
NCrunch NCrunch is a powerful tool that automates the testing and debugging of .NET and C# code. It integrates seamlessly into Visual Studio, allowing development teams to quickly identify and fix errors, ensuring that their projects are always of the...
Oct 26, 2023
Author: Matt Bentley
How to implement CQRS in ASP.NET using MediatR. A guided example using CQRS with separate Read and Write models using Enity Framework Core for Commands and Dapper for Queries. When people think about CQRS they often think about complex, event-driven,...
Jun 13
Author: Dayanand Thombare
Creating background services in .NET Core is a powerful way to perform long-running, background tasks that are independent of user interaction. These tasks can range from data processing, sending batch emails, to file I/O operations — all critical for today’s...
Jul 23, 2023
Unlocking Resilience and Transient-fault-handling in your C# Code In an ideal world, every operation we execute, every API we call, and every database we query, would always work flawlessly. Unfortunately, we live in a world where network outages, server overloads,...
Send message
Type
Email
Your name
*Message