Asked  7 Months ago    Answers:  5   Viewed   61 times

I have services that are derived from the same interface.

public interface IService { }
public class ServiceA : IService { }
public class ServiceB : IService { } 
public class ServiceC : IService { }

Typically, other IoC containers like Unity allow you to register concrete implementations by some Key that distinguishes them.

In ASP.NET Core, how do I register these services and resolve them at runtime based on some key?

I don't see any Add Service methods that take a key or name parameter, which would typically be used to distinguish the concrete implementation.

    public void ConfigureServices(IServiceCollection services)
         // How do I register services of the same interface?            

    public MyController:Controller
       public void DoSomething(string key)
          // How do I resolve the service by key?

Is the Factory pattern the only option here?

I have gone though the article here that shows how to use the factory pattern to get service instances when we have multiple concrete implementations. However, it is still not a complete solution. When I call the _serviceProvider.GetService() method, I cannot inject data into the constructor.

For example consider this:

public class ServiceA : IService
     private string _efConnectionString;
     ServiceA(string efconnectionString)
       _efConnecttionString = efConnectionString;

public class ServiceB : IService
   private string _mongoConnectionString;
   public ServiceB(string mongoConnectionString)
      _mongoConnectionString = mongoConnectionString;

public class ServiceC : IService
    private string _someOtherConnectionString
    public ServiceC(string someOtherConnectionString)
      _someOtherConnectionString = someOtherConnectionString;

How can _serviceProvider.GetService() inject the appropriate connection string? In Unity, or any other IoC library, we can do that at type registration. I can use IOption, however, that will require me to inject all settings. I cannot inject a particular connection string into the service.

Also note that I am trying to avoid using other containers (including Unity) because then I have to register everything else (e.g., Controllers) with the new container as well.

Also, using the factory pattern to create service instances is against DIP, as it increases the number of dependencies a client has details here.

So, I think the default DI in ASP.NET Core is missing two things:

  1. The ability to register instances using a key
  2. The ability to inject static data into constructors during registration



I did a simple workaround using Func when I found myself in this situation.

Firstly declare a shared delegate:

public delegate IService ServiceResolver(string key);

Then in your Startup.cs, setup the multiple concrete registrations and a manual mapping of those types:


services.AddTransient<ServiceResolver>(serviceProvider => key =>
    switch (key)
        case "A":
            return serviceProvider.GetService<ServiceA>();
        case "B":
            return serviceProvider.GetService<ServiceB>();
        case "C":
            return serviceProvider.GetService<ServiceC>();
            throw new KeyNotFoundException(); // or maybe return null, up to you

And use it from any class registered with DI:

public class Consumer
    private readonly IService _aService;

    public Consumer(ServiceResolver serviceAccessor)
        _aService = serviceAccessor("A");

    public void UseServiceA()

Keep in mind that in this example the key for resolution is a string, for the sake of simplicity and because OP was asking for this case in particular.

But you could use any custom resolution type as key, as you do not usually want a huge n-case switch rotting your code. Depends on how your app scales.

Tuesday, June 1, 2021
answered 7 Months ago

The way I make my dropdowns is somewhat similar except that in my ViewModel, my property is of type SelectList instead of an IEnumerable<>.

public class HomeViewModel
    public string CountryCode { get; set; }
    public SelectList CountryList { get; set; }

Then in the controller I get the data and convert it to an anonymous list with two properties “Id” and “Value”.

In turn, I create a new SelectList() passing in the anonymous list specifying what is the dataValueField and what is the dataTextField.

public IActionResult Index()
    var countries = _customersContext.Countries.OrderBy(c => c.CountryName).Select(x => new { Id = x.Code, Value = x.Name });

    var model = new HomeViewModel();
    model.CountryList = new SelectList(countries, "Id", "Value");

    return View(model);

Finally, in the View:

<div class="form-group">
    <label asp-for="CountryCode" class="col-md-2 control-label"></label>
    <div class="col-md-10">
        <select asp-for="CountryCode" asp-items="@Model.CountryList"></select>
Wednesday, June 30, 2021
answered 5 Months ago

It should be enough to name your mocks serviceA and serviceB. From Mockito documentation:

Property setter injection; mocks will first be resolved by type, then, if there is several property of the same type, by the match of the property name and the mock name.

In your example:

@InjectMocks ServiceCaller classUnderTest;

@Mock SomeService serviceA;
@Mock SomeService serviceB;

Note that it is not necessary to manually create class instance when using @InjectMocks.

Nevertheless I personally prefer injecting dependencies using constructor. It makes it easier to inject mocks in tests (just call a constructor with your mocks - without reflections tools or @InjectMocks (which is useful, but hides some aspects)). In addition using TDD it is clearly visible what dependencies are needed for the tested class and also IDE can generate your constructor stubs.

Spring Framework completely supports constructor injection:

public class ServiceCaller {
    private final SomeService serviceA;
    private final SomeService serviceB;

    public ServiceCaller(@Qualifier("serviceA") SomeService serviceA,
                         @Qualifier("serviceB") SomeService serviceB) { ... }


This code can be tested with:

@Mock SomeService serviceA;
@Mock SomeService serviceB;

//in a setup or test method
ServiceCaller classUnderTest = new ServiceCaller(serviceA, serviceB); 
Wednesday, August 11, 2021
answered 4 Months ago

is all you need. I prefer this to zip 50% of the time.

Tuesday, August 24, 2021
answered 4 Months ago

In general terms IActionResult type is a base abstraction of an action result. It is used as the base of other derived action results that represent specific response types, of which there are many.

Reference Asp.Net Core Action Results Explained

IActionResult and ActionResult

IActionResult and ActionResult work as a container for other action results, in that IActionResult is an interface and ActionResult is an abstract class that other action results inherit from. So they can’t be newed up and returned like other action results. IActionResult and ActionResult have not much of a different from usability perspective, but since IActionResult is the intended contract for action results, it’s better to use it as opposed to ActionResult. IActionResult/ActionResult should be used to give us more flexibility, like when we need to return different type of response based on user interaction.

To quote official documentation Found here Controller action return types in ASP.NET Core Web API

The IActionResult return type is appropriate when multiple ActionResult return types are possible in an action. The ActionResult types represent various HTTP status codes. Some common return types falling into this category are BadRequestResult (400), NotFoundResult (404), and OkObjectResult (200).

Wednesday, September 29, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :