Como resolver manualmente um tipo usando a estrutura de injeção de dependência interna do ASP.NET Core MVC?

A configuração do contêiner é fácil:

public void ConfigureServices(IServiceCollection services)
{
    // ...

    services.AddTransient<ISomeService, SomeConcreteService>();
}

Mas como posso resolver ISomeServicesem executar a injeção? Por exemplo, eu quero fazer isso:

ISomeService service = services.Resolve<ISomeService>();

Não existem tais métodos no IServiceCollection.

A IServiceCollectioninterface é usada para criar um contêiner de injeção de dependência. Depois de totalmente construído, ele é composto por uma IServiceProviderinstância que você pode usar para resolver serviços. Você pode injetar um IServiceProviderem qualquer classe. As classes IApplicationBuildere também HttpContextpodem fornecer o provedor de serviços, por meio de suas propriedades ApplicationServicesou RequestServices.

IServiceProviderdefine um GetService(Type type)método para resolver um serviço:

var service = (IFooService)serviceProvider.GetService(typeof(IFooService));

Existem também vários métodos de extensão de conveniência disponíveis, como serviceProvider.GetService<IFooService>()(adicione um usingparaMicrosoft.Extensions.DependencyInjection ).

Resolvendo serviços dentro da classe de inicialização

Injetando dependências

Provedor de serviço do tempo de execução pode injetar certos serviços para o construtor da Startupclasse, tais como IConfiguration, IWebHostEnvironment( IHostingEnvironmentem pré-versões 3.0), ILoggerFactorye IServiceProvider. Observe que a última é uma instância criada pela camada de hospedagem e contém apenas os serviços essenciais para iniciar um aplicativo .

O ConfigureServices()método não permite a injeção de serviços, apenas aceita um IServiceCollectionargumento. Isso faz sentido porque ConfigureServices()é onde você registra os serviços exigidos pelo seu aplicativo. No entanto, você pode usar serviços injetados no construtor da inicialização aqui, por exemplo:

public Startup(IConfiguration configuration)
{
    Configuration = configuration;
}

public IConfiguration Configuration { get; }

public void ConfigureServices(IServiceCollection services)
{
    // Use Configuration here
}

Quaisquer serviços registrados ConfigureServices()podem ser injetados no Configure()método; você pode adicionar um número arbitrário de serviços após o IApplicationBuilderparâmetro:

public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<IFooService>();
}

public void Configure(IApplicationBuilder app, IFooService fooService)
{
    fooService.Bar();
}

Resolução manual de dependências

Se você precisar resolver serviços manualmente, use preferencialmente o ApplicationServicesfornecido por IApplicationBuilderno Configure()método:

public void Configure(IApplicationBuilder app)
{
    var serviceProvider = app.ApplicationServices;
    var hostingEnv = serviceProvider.GetService<IHostingEnvironment>();
}

É possível passar e usar diretamente um IServiceProviderno construtor de sua Startupclasse, mas, como acima, ele conterá um subconjunto limitado de serviços e, portanto, possui utilidade limitada:

public Startup(IServiceProvider serviceProvider)
{
    var hostingEnv = serviceProvider.GetService<IWebHostEnvironment>();
}

Se você precisar resolver serviços no ConfigureServices()método, será necessária uma abordagem diferente. Você pode criar um intermediário a IServiceProviderpartir da IServiceCollectioninstância que contém os serviços que foram registrados até aquele momento :

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IFooService, FooService>();

    // Build the intermediate service provider
    var sp = services.BuildServiceProvider();

    // This will succeed.
    var fooService = sp.GetService<IFooService>();
    // This will fail (return null), as IBarService hasn't been registered yet.
    var barService = sp.GetService<IBarService>();
}

Observação: geralmente você deve evitar resolver serviços dentro do ConfigureServices()método, pois esse é realmente o local em que você está configurando os serviços de aplicativo. Às vezes, você só precisa acessar uma IOptions<MyOptions>instância. Você pode fazer isso vinculando os valores da IConfigurationinstância a uma instância de MyOptions(que é essencialmente o que a estrutura de opções faz):

public void ConfigureServices(IServiceCollection services)
{
    var myOptions = new MyOptions();
    Configuration.GetSection("SomeSection").Bind(myOptions);
}

A resolução manual de serviços (aka Service Locator) é geralmente considerada um antipadrão . Embora tenha seus casos de uso (para estruturas e / ou camadas de infraestrutura), você deve evitá-lo o máximo possível.

A resolução manual de instâncias envolve o uso do método IServiceProvider interface:

Resolvendo dependência em Startup.ConfigureServices

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IMyService, MyService>();

    var serviceProvider = services.BuildServiceProvider();
    var service = serviceProvider.GetService<IMyService>();
}

Resolvendo dependências na inicialização.

public void Configure(
    IApplicationBuilder application,
    IServiceProvider serviceProvider)
{
    // By type.
    var service1 = (MyService)serviceProvider.GetService(typeof(MyService));

    // Using extension method.
    var service2 = serviceProvider.GetService<MyService>();

    // ...
}

Resolvendo dependências no Startup.Configure no ASP.NET Core 3

public void Configure(
    IApplicationBuilder application,
    IWebHostEnvironment webHostEnvironment)
{
    app.ApplicationServices.GetService<MyService>();
}

Usando serviços injetados em tempo de execução

Alguns tipos podem ser injetados como parâmetros de método:

public class Startup
{
    public Startup(
        IHostingEnvironment hostingEnvironment,
        ILoggerFactory loggerFactory)
    {
    }

    public void ConfigureServices(
        IServiceCollection services)
    {
    }

    public void Configure(
        IApplicationBuilder application,
        IHostingEnvironment hostingEnvironment,
        IServiceProvider serviceProvider,
        ILoggerFactory loggerfactory,
        IApplicationLifetime applicationLifetime)
    {
    }
}

Resolvendo dependências em ações do controlador

[HttpGet("/some-action")]
public string SomeAction([FromServices] IMyService myService) => "Hello";

Se você gerar um aplicativo com um modelo, terá algo parecido com isto na Startupclasse:

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddApplicationInsightsTelemetry(Configuration);

    services.AddMvc();
}

Você pode adicionar dependências lá, por exemplo:

services.AddTransient<ITestService, TestService>();

Se você deseja acessar ITestServiceno seu controlador, você pode adicionar IServiceProvidero construtor e ele será injetado:

public HomeController(IServiceProvider serviceProvider)

Em seguida, você pode resolver o serviço que você adicionou:

var service = serviceProvider.GetService<ITestService>();

Observe que, para usar a versão genérica, é necessário incluir o espaço para nome com as extensões:

using Microsoft.Extensions.DependencyInjection;

ITestService.cs

public interface ITestService
{
    int GenerateRandom();
}

TestService.cs

public class TestService : ITestService
{
    public int GenerateRandom()
    {
        return 4;
    }
}

Startup.cs (ConfigureServices)

public void ConfigureServices(IServiceCollection services)
{
    services.AddApplicationInsightsTelemetry(Configuration);
    services.AddMvc();

    services.AddTransient<ITestService, TestService>();
}

HomeController.cs

using Microsoft.Extensions.DependencyInjection;

namespace Core.Controllers
{
    public class HomeController : Controller
    {
        public HomeController(IServiceProvider serviceProvider)
        {
            var service = serviceProvider.GetService<ITestService>();
            int rnd = service.GenerateRandom();
        }

Se você apenas precisar resolver uma dependência com a finalidade de transmiti-la ao construtor de outra dependência que está registrando, poderá fazer isso.

Digamos que você tenha um serviço que tenha uma string e um ISomeService.

public class AnotherService : IAnotherService
{
    public AnotherService(ISomeService someService, string serviceUrl)
    {
        ...
    }
}

Quando você registrar isso em Startup.cs, precisará fazer o seguinte:

services.AddScoped<IAnotherService>(ctx => 
      new AnotherService(ctx.GetService<ISomeService>(), "https://someservice.com/")
);

Você pode injetar dependências em atributos como AuthorizeAttribute dessa maneira

var someservice = (ISomeService)context.HttpContext.RequestServices.GetService(typeof(ISomeService));

Eu sei que esta é uma pergunta antiga, mas estou surpreso que um hack bastante óbvio e nojento não esteja aqui.

Você pode explorar a capacidade de definir sua própria função de ctor para obter os valores necessários de seus serviços conforme você os define ... obviamente isso seria executado toda vez que o serviço fosse solicitado, a menos que você explicitamente remova / limpe e adicione novamente a definição de este serviço na primeira construção do ctor explorador .

Esse método tem a vantagem de não exigir que você construa a árvore de serviços ou use-a durante a configuração do serviço. Você ainda está definindo como os serviços serão configurados.

public void ConfigureServices(IServiceCollection services)
{
    //Prey this doesn't get GC'd or promote to a static class var
    string? somevalue = null;

    services.AddSingleton<IServiceINeedToUse, ServiceINeedToUse>(scope => {
         //create service you need
         var service = new ServiceINeedToUse(scope.GetService<IDependantService>())
         //get the values you need
         somevalue = somevalue ?? service.MyDirtyHack();
         //return the instance
         return service;
    });
    services.AddTransient<IOtherService, OtherService>(scope => {
         //Explicitly ensuring the ctor function above is called, and also showcasing why this is an anti-pattern.
         scope.GetService<IServiceINeedToUse>();
         //TODO: Clean up both the IServiceINeedToUse and IOtherService configuration here, then somehow rebuild the service tree.
         //Wow!
         return new OtherService(somevalue);
    });
}

A maneira de corrigir esse padrão seria fornecer OtherServiceuma dependência explícita IServiceINeedToUse, em vez de depender implicitamente dele ou do valor de retorno do seu método ... ou resolver essa dependência explicitamente de alguma outra maneira.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.AddDbContext<ConfigurationRepository>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("SqlConnectionString")));

    services.AddScoped<IConfigurationBL, ConfigurationBL>();
    services.AddScoped<IConfigurationRepository, ConfigurationRepository>();
}