1

There a quite a couple of similar questions but they don't seem to address this specific use case.

From my configuration (run time), I am trying to create multiple instances of a certain object (same implementation, same interface) which should have an application life time scope.

Reading the doc's I see

  • Scoped lifetime (as per http request)
  • Transient (as per resolvure)
  • Singleton (application lifetime)

So basically I need the singleton, but, I need multiple of them.

The .AddSingleton method and overloads doesn't seem to support any named instances.

I checked out this question, but there they are using a different (Transient) scope.

I am able to put a Name property in the interface,

Is there a way to create (and resolve) multiple similar object with the same implementation and interface with an application life time scope?

Stefan
  • 17,448
  • 11
  • 60
  • 79

3 Answers3

1

Okay, I think the AddSingleton name is a bit inconvenient; it seems you can register multiple "singleton" instances by using .AddSingleton.

So, basically the following setup just works:

//some class
public class Foo
{
    public string Name { get; set; }
}

With registration:

services.AddSingleton(new Foo { Name = "1" });
services.AddSingleton(new Foo { Name = "2" });

And resolving will result in 2 "singletons":

//note: this is just a test to resolve them: do not use this in your code.
services.BuildServiceProvider().GetServices(typeof(Foo));

The essence of this question, and answer, is that .AddSingleton doesn't seem to relate to the Singleton pattern at all.

This is what I mean:

enter image description here

Stefan
  • 17,448
  • 11
  • 60
  • 79
1

Net Core DI doesnt natively support named instances. I'm fairly sure that the implementing it the way you have detailed isnt really supported. AFAIK you have two options,

  1. Use a different 3rd party DI provider (Ninject, SimpleInjector Autofac etc)
  2. Use the factory pattern to create a factory object that lets you resolve the object you want and use the services.AddXXX overload methods to pass in your factory class

Additionally, this could be a duplicate of: Dependency injection resolving by name

Robert Perry
  • 1,906
  • 1
  • 14
  • 14
  • Are you suggesting that this is what you want to do? services.AddSingleton(new Foo {Name = "1"}); services.AddScoped(new Foo { Name = "2" }); services.AddTransient(new Foo {Name = "3"}); – Robert Perry Feb 06 '19 at 09:49
  • In which case, my answer is valid, and although worded differently, it is the same question as the duplicate I mentioned – Robert Perry Feb 06 '19 at 09:57
  • No, it isn't. It might be the same answer, but it isn't the same question. The question is about **application lifetime scope** for multiple object of the same type. No such thing is mentioned in the duplicate *question*. – Stefan Feb 06 '19 at 10:06
  • Nevertheless if you think it's a duplicate; mark it as such. If you can't I will do it for you and see what happens. The essence of this question, and answer is that "AddSingleton" doen't seem to relate to the "Singleton" pattern at all. – Stefan Feb 06 '19 at 10:08
  • @Stefan, Singleton pattern stays for _Ensure a **class** has only one instance_, so looks like `AddSingleton` nicely supports requirements ;) – Fabio Feb 06 '19 at 10:57
  • @Fabio: no it doesn't: see my answer. – Stefan Feb 06 '19 at 10:58
1

DI requires little bit more information about how to resolve required types/instances.
You mention only one part of the problem - registration of multiple instances of same type, but what about how those instances will be consumed.
Consumption will affect on how instances should be registered.

In a case you need different instances for different cases - you can create a singleton wrapper which will contain all required instances with correspondent name

public class Wrapper
{
    public IRepository Orders { get; }
    public IRepository Deliveries { get; }
    public IRepository Products { get; }

    public Wrapper(IRepository orders, IRepository deliveries, IRepository products)
    {
        Orders = orders;
        Deliveries = deliveries;
        Products = products
    }
}

IRepository will be registered as Transient, but wrapper as Singleton

services.AddTransient<IRepository, SqlRepository>();
services.AddSingleton<Wrapper>();

Whenever you need one of those instances you will inject a wrapper as a dependency and use required instance through well-named property

public class Consumer
{
    private readonly Wrapper _data;

    public Consumer(Wrapper data) => _data = data;

    public void DoSomething()
    {
        var myProducts = _data.Products.GetMy();
        // ...
    }
}

Because DI need to know how to instantiate different instances of same class, we need to create some workaround.

Another approach is to create different types for every required instance and which will derive from original one and register them as singleton types.

public class SqlRepository 
{ 
    public void GetData() { }
}

public class Orders : SqlRepository 
{ 
    // Nothing extra
}

public class Products : SqlRepository 
{ 
    // Nothing extra
}

And registration

services.AddSingleton<SqlRepository>();
services.AddSingleton<Orders>();
services.AddSingleton<Products>();

So consumers will have required type as a dependency and only one instance for every type will be instantiated within DI.

Fabio
  • 31,528
  • 4
  • 33
  • 72
  • Yes, this is a good solution if you would't be requiring a run-time configuration ;-) Nevertheless, there are options in this answer. – Stefan Feb 06 '19 at 10:50
  • @Stefan, another approach to have dedicated types for every instance, check updated answer. – Fabio Feb 06 '19 at 10:55