Optional constructor injection arguments with .NET Core

Question

In some IoC containers it is possible to have arguments in the constructor that can't be fulfilled by the container. Is this possible with the Microsoft.Extensions.DependencyInjection libraries and IServiceProvider? If not, what is a clean solution for this sort of problem?

For example:

class InContainer
{
    public InContainer(NotInContainer dependency) { ... }
}

class Consumer
{
    public Consumer(IServiceProvider serviceProvider)
    {
         NotInContainer currentDependency = ... // from some other source
         // passing the anonymous object here is not supported, 
         // but I would like to 
         InContainer = serviceProvider.GetService<InContainer>(
             new { dependency = currentDependency }
         );
    }
}

Do you mean during registration, or on a per instance basis? — ste-fu
– ste-fu, Commented Nov 3, 2017 at 13:03

Steven · Accepted Answer · 2017-11-03 14:51:58Z

5

In your example, you provide the serviceProvider with a runtime value currentDependency. Application components should not require runtime data during construction, as explained here. The solution is to refactor your design, as explained in that article.

About optional arguments:

The fact that some DI Containers support optional arguments, doesn't make it a good practice to use them. As a matter of fact, injection constructor arguments should never be optional.

As explained in this article:

An optional dependency implies that the reference to the dependency will be null when it’s not supplied. Null references complicate code because they require specific logic for the null-case. Instead of passing in a null reference, the caller could insert an implementation with no behavior, i.e. an implementation of the Null Object Pattern.

If not, what is a clean solution for this sort of problem?

As stated, the Null Object pattern is the solution for this, even when using a DI Container that actually supports optional constructor dependencies.

edited Nov 3, 2017 at 14:51

answered Nov 3, 2017 at 13:17

Steven

174k26 gold badges355 silver badges453 bronze badges

Sign up to request clarification or add additional context in comments.

6 Comments

Evk Over a year ago

But OP dependency is not optional. It is just not present in container and he wants to provide it at resolve time.

Evk Over a year ago

Yes that makes sense, but still first part of your answer seems not relevant to the question.

Steven Over a year ago

@Evk: well.... according to the title, the question is about "optional constructor arguments" :)

Daniel A. White Over a year ago

This doesn’t seem like it would work well for my situation

Evk Over a year ago

You have the point :) Though I usually ignore titles since they very often are different from what is being asked. In case of your answer one might not even reach last paragraph, think that first part is not relevant for their sutation and downvote.

|

Haukinger · Accepted Answer · 2017-11-03 13:18:22Z

3

Normally, I create a factory by hand in this case.

public class TheFactory
{
    public TheFactory( SomeType fromContainer )
    {
        _fromContainer = fromContainer;
    }

    public IProduct Create( SomeOtherType notFromContainer ) => new TheProduct( _fromContainer, notFromContainer );

    private readonly SomeType _fromContainer;

    private class TheProduct : IProduct
    {
        // ...
    }
}

If you need per-product dependencies from the container, the factory's Create has to resolve them. Or, in the case of e.g. unity, the factory gets a Func from the container.

answered Nov 3, 2017 at 13:18

Haukinger

10.9k2 gold badges20 silver badges33 bronze badges

2 Comments

Daniel A. White Over a year ago

I suppose then the factory could track any ‘IDisposable’s and clean them up.

Haukinger Over a year ago

It probably doesn't even need to, given you treat a call to Create the same way as new - it creates an instance that belongs to the caller.

pbristow · Accepted Answer · 2018-10-03 20:51:37Z

1

Is there a reason not to just do this? I had a situation where I needed the HttpContext, but in the course of initializing my web app, a few calls would inevitably be made. Since it was during init, there was no request and hence no context.

This was all for fairly typical database auditing, by the way, so obviously you want the username for changes the user makes, but during init it just ends up using "SYSTEM" or something like that. So...

public class CurrentHttpUserProvider : ICurrentUserProvider
{
    public CurrentHttpUserProvider(IServiceProvider container)
    {
        var httpContext = container.GetService(typeof(HttpContext)); // just returns null if it can't be found...
        if (httpContext != null)
            CurrentUser = ((HttpContext)httpContext).User.Identity.Name;
        else
            CurrentUser = "SYSTEM";
    }

    public string CurrentUser { get; set; }
}

This seems to be like it would be 100% as efficient as if I'd just injected the HttpContext as a constructor param, but perhaps I'm wrong.

answered Oct 3, 2018 at 20:51

pbristow

2,2054 gold badges30 silver badges48 bronze badges

3 Comments

Mathias Lykkegaard Lorenzen Over a year ago

You're using the Service Locator anti-pattern. That's one reason one might not use it.

Dave Over a year ago

I know this is old, but there is an IHttpContextAccessor that can be used for this purpose. It contains a property for the HttpContext that can be null.

pbristow Over a year ago

@Dave You're 100% right. This is very old. The correct way to do it these days is with IHttpContextAccessor. I either didn't know about it back then or for some reason it didn't work for me then.

Collectives™ on Stack Overflow

Optional constructor injection arguments with .NET Core

3 Answers 3

6 Comments

2 Comments

3 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

3 Answers 3

6 Comments

2 Comments

3 Comments

Your Answer

Sign up or log in

Post as a guest

Related