DEV Community: Haiyang Wang

Exercises on Dependency Injection in ASP.NET - Basics

Haiyang Wang — Thu, 25 Jun 2020 06:31:37 +0000

In this post, we will do some exercises to go over the basics of DI(Dependency Injection) in ASP.NET.

Accessibility Levels

What's the result of the following code?

public interface IServiceA { }

class ServiceA : IServiceA
{
    ServiceA()
    {
        Console.WriteLine("New SA");
    }
}

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddTransient<IServiceA, ServiceA>();
        ...
    }
}

It will raise an exception:

System.AggregateException: 'Some services are not able to be constructed'
A suitable constructor for type 'AspNetCore.Services.ServiceA' could not be located.
Ensure the type is concrete and services are registered for all parameters of a public constructor.

As mentioned in ASP.NET Core doc, constructor injection requires a public constructor.

Why public constructor? Because the default accessibility level of constructor is private. DI is implemented by ASP.NET Core, it cannot access other levels except public.

Why not public class? Because the DI framework already gets the class by method call. If we want to access a class by using namespace, public is needed.

Life Cycle

When the following app is running without any request coming, will the singleton service be initialized?

public interface IServiceA { }

public class ServiceA : IServiceA
{
    public ServiceA()
    {
        Console.WriteLine("New SA");
    }
}
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<IServiceA, ServiceA>();
        ...
    }
}
public class HelloController : ControllerBase
{
    public WeatherForecastController(IServiceA sa)
    {
        Console.WriteLine($"Test Controller: {sa.GetHashCode()}");
    }
}

The ServiceA won't be initialized. The DI framework will check the constructor(I guess), but won't initialize the instance. It is only when the singleton service is used that it will be initialized.

In this case, the service is depended by the controller, and the controller will be initialized for every request. So, as a singleton service, the ServiceA will be initialized when the first request comes. When other requests come after the first request, the singleton service won't be initialized any more:

// 1st request
New SA
Test Controller: 83452835
// 2nd request
Test Controller: 83452835
// 3rd request
Test Controller: 83452835

If we use AddScoped instead of AddSingleton, the DI framework will initialize a new instance for every request.

// 1st request
New SA
Test Controller: 72334852
// 2nd request
New SA
Test Controller: 83729442
// 3rd request
New SA
Test Controller: 19231424

Initialization Order

If we inject dependencies in order of A-B, and fetch them in order of B-A, which one will be initialized first?

public interface IServiceA { }
public class ServiceA : IServiceA
{
    public ServiceA()
    {
        Console.WriteLine("New SA");
    }
}

public interface IServiceB { }
public class ServiceB : IServiceB
{
    public ServiceB()
    {
        Console.WriteLine("New SB");
    }
}

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<IServiceA, ServiceA>();
        services.AddSingleton<IServiceB, ServiceB>();
        ...
    }
}

public class HelloController : ControllerBase
{
    public WeatherForecastController(IServiceB sb, IServiceA sa)
    {
        Console.WriteLine($"Test Controller: {sa.GetHashCode()}");
    }
}

Result:

New SB
New SA
Test Controller: 83427434 22834295

Although the injection order is A-B, but B will be first initialized because we fetch B first.

What if B depends on A?

public class ServiceB : IServiceB
{
    public ServiceB(IServiceA sa)
    {
        Console.WriteLine($"New SB with sa: {sa.GetHashCode()}");
    }
}

Result:

New SA
New SB with sa: 46284926
Test Controller: 46284926 64753745

ServiceA will be initialized first, then ServiceB. And because ServiceA is singleton, it will not be initialized again.

What if we inject B before A, but B depends on A?

public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<IServiceB, ServiceB>();
    services.AddScoped<IServiceA, ServiceA>();
}

Result:

New SA
New SB with sa: 72362183
Test Controller: 72362183 91218567

The order of injection doesn't matter. The DI container will keep the relationship between the interface and the implement class, and will properly handle everything for us at initialization time.

One Interface & Multiple Implement

If there are multiple implement class and they are all injected, which one will be initialized?

public interface IServiceA { }
public class ServiceA : IServiceA
{
    public ServiceA()
    {
        Console.WriteLine("New SA");
    }
}
public class ServiceB : IServiceA
{
    public ServiceB()
    {
        Console.WriteLine("New SB");
    }
}

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<IServiceA, ServiceA>();
        services.AddSingleton<IServiceA, ServiceB>();
        ...
    }
}

public class HelloController : ControllerBase
{
    public WeatherForecastController(IServiceA sa)
    {
        Console.WriteLine($"Test Controller: {sa.GetHashCode()}");
    }
}

Result:

New SB
Test Controller: 46399782

Only the last one will be initialized. If you want the first one, use TryAdd. TryAdd won't work if there already exists a registration for the given service interface.

Multiple Interface & One Implement

If there is multiple interfaces and only one implement class registered as singleton, how many times will it be initialized?

public interface IServiceA { }
public interface IServiceB { }
public class ServiceB : IServiceA, IServiceB
{
    public ServiceB()
    {
        Console.WriteLine("New SB");
    }
}

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<IServiceA, ServiceB>();
        services.AddSingleton<IServiceB, ServiceB>();
        ...
    }
}

public class HelloController : ControllerBase
{
    public WeatherForecastController(IServiceA sa, IServiceB sb)
    {
        Console.WriteLine($"Test Controller: {sa.GetHashCode()} {sb.GetHashCode()}");
    }
}

Result:

New SB
New SB
Test Controller: 78346274

As you see, the singleton in AddSingleton refers to the interface not the implement. ServicesB is the implement class of two interfaces, they will be initialized separately.

Follow Up

All these exercises are very basic and common. Some parts are just my personal opnion. I am a ASP.NET Core beginner, please correct my if you think anything is wrong.

If you want to learn more about DI in ASP.NET Core, source code of Microsoft.Extensions.DependencyInjection is a good reading.

References:

Yo, Yo, Check Null

Haiyang Wang — Sat, 20 Jun 2020 11:58:56 +0000

It is a very common practice to check for null in parameters:

public void DoSomething(Foo foo)
{
    if (foo is null)
    {
        throw new ArgumentNullException(nameof(foo));
    }
}

In this blog, I want to talk about parameter null validation: why, when, and how.

Why

It's suggested in many coding style rules, it's followed in many open source projects, but why? What would happen if we don't check whether the parameter is null? What's the benefit of it?

Let's take a look at the following example:

public void PrintCar(Car car)
{
    if (car is null)
    {
        throw new ArgumentNullException(nameof(foo));
    }
    Console.WriteLine(car.Name);
}

In this case, if we don't check whether the parameter is null, it will raise NullReferenceException; if we check, it will raise ArgumentNullException. It looks like the NullReferenceException is gone, but actually we get a new ArgumentNullException. The caller still has to handle it. The number of exceptions doesn't change at all.

Referring to Voldemort as 'You-Know-Who' cannot kill him.

If a method catches an exception and doesn't has the ability to handle it, is it needed to check the null parameters?

Different people have different opinions.

In the blog , the author made a point that it doesn't make sense if you catch the exception and ignore it.

In my opinion, parameters null validation is necessary and useful in most cases.

The first reason is that, NullReferenceException is different from ArgumentNullException. The name of exceptions can help us find the responsible party. If you call the method and you get a ArgumentNullException, you may figure out there is something wrong with the parameters. Just like 40x and 50x status code in HTTP. Bad Request is totally different from Server Error.

The second reason is that, most methods are not stateless. In these stateful methods, an exception in the middle of the method will mess the states up and we cannot roll back easily.

Take a look at this example:

public void CarCounter(Car car)
{
    // #1
    this.CarCount += 1;
    // #2
    this.CarNames.Add(car.Name);
}

When car is null, it will raise an exception in line #2. However, there is a state update in line #1. This may modify the count incorrectly. We need a mechanism like transaction in DB to roll back the executed part of the method. It may be very complicated. And for some cases like notification, the actions are irrevocable.

As a conclusion, in most cases parameter null validation is necessary and useful. It can avoid the execution which shouldn't happen, and it can specify the responsibility of the unexpected exception.

When

As we talked above, it's meaningful to check the null parameters. But should we check all method parameters in our projects?

It depends.

For public method, we don't know what parameters the caller will pass, we should check null parameters before the business logic.

For private methods, we needn't check because we are supposed to know how and where this method is called. In this situation, the null variables should be checked outside of the method before calling it.

It's a good choice to enable the CA1062 Warning. With this warning, we needn't care about when to validate the parameters. Just think about which access modifier should be used, public or private.

How

The following question is, how to check null parameters. The code for validation is verbose and useless. Validating null parameters everywhere will make the code less human-readable.

In the blog , the author went through many ways to validate the parameters. The C# Proposal #2145 about bang operator is very interesting and I am really looking forward to it.

Given Code Contract is deprecated, wrapping the validation into a Helper is a better choice:

internal static class ThrowIf
{
    public static class Argument
    {
        public static void IsNull<T>(T argument, string name)
        {
            if (argument is null)
            {
                throw new ArgumentNullException(name);
            }
        }
    }
}
public void DoSomething(Foo foo)
{
    ThrowIf.Argument.IsNull(foo, nameof(foo));
}

Please let me know if you have another solution. Thanks.

References:

Update:
Thanks to Sam for suggesting replace == null with is null because the == operator can be overloaded.

Update2:
Thanks to sunilmusinada for suggesting replace hardcode param type with nameof.

Update3:
Thanks to Zohar for pointing out the mistake I made that I put the parameter's type name in exception instead of the parameter's name