Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow resolving types with unregistered optional dependencies #724

Open
chivandikwa opened this issue Jun 7, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@chivandikwa
Copy link

commented Jun 7, 2019

I just discovered that Simple Injector cannot resolve dependencies that have an unregistered optional dependency in it's ctor. For example:

internal interface ISample { }

internal class Sample : ISample
{
    public Sample(Dictionary<string, string> junk = null) { }
}

class Program
{
    static void Main(string[] args)
    {
        var container = new Container();

        container.Register<ISample, Sample>();

        container.Verify();
    }
}

Here because the container is not aware of the type Dictionary<string, string> it fails on verify. However because the dependency is nullable should Simple Injector not be able to resolve this? Naturally I expected this would be handled but wondering if this clashes with some design decisions of Simple Injector.

@chivandikwa chivandikwa added the question label Jun 7, 2019

@dotnetjunkie

This comment has been minimized.

Copy link
Collaborator

commented Jun 8, 2019

However because the dependency is nullable should SimpleInjector not be able to resolve this

This is a very explicit design decision. A constructor declares a component's required dependencies. It, therefore, doesn't make sense to make a required dependency optional. Instead of making dependencies optional, a better solution is to apply the Null Object pattern. This simplifies the consumer, because it has guarantee about the availability of the dependency, and doesn't need to do null checks in its code (only a guard check within its constructor).

Concequence is, however, that you move the responsibility of always providing the dependency into the Composition Root. The Composition Root should ensure a valid (but perhaps empty) implementation of the dependency is provided. Letting the Composition Root handle this, opposed to leaking these details into the consuming component, however, is simpler, safer, and more maintainable.

@dotnetjunkie dotnetjunkie changed the title Resolve types with nullable dependencies that are not registered Allow resolving types with unregistered optional dependencies Jun 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.