¿Cómo resuelvo manualmente un tipo usando el marco de inyección de dependencia incorporado ASP.NET Core MVC?

Configurar el contenedor es bastante fácil:

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

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

Pero, ¿cómo puedo resolver ISomeServicesin realizar la inyección? Por ejemplo, quiero hacer esto:

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

No hay tales métodos en IServiceCollection.

La IServiceCollectioninterfaz se usa para construir un contenedor de inyección de dependencia. Una vez que está completamente construido, se compone de una IServiceProviderinstancia que puede usar para resolver servicios. Puede inyectar un IServiceProvideren cualquier clase. Los IApplicationBuildery HttpContextlas clases pueden proporcionar el proveedor de servicio, así, a través de sus ApplicationServiceso RequestServicespropiedades respectivamente.

IServiceProviderdefine un GetService(Type type)método para resolver un servicio:

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

También hay varios métodos de extensión de conveniencia disponibles, como serviceProvider.GetService<IFooService>()(agregar un usingpara Microsoft.Extensions.DependencyInjection).

Resolviendo servicios dentro de la clase de inicio

Inyectando dependencias

Proveedor de alojamiento de servicio del tiempo de ejecución puede inyectar ciertos servicios en el constructor de la Startupclase, tales como IConfiguration, IWebHostEnvironment( IHostingEnvironmenten pre-3.0 versiones), ILoggerFactoryy IServiceProvider. Tenga en cuenta que esta última es una instancia creada por la capa de alojamiento y contiene solo los servicios esenciales para iniciar una aplicación .

El ConfigureServices()método no permite inyectar servicios, solo acepta un IServiceCollectionargumento. Esto tiene sentido porque ConfigureServices()es donde registra los servicios requeridos por su aplicación. Sin embargo, puede utilizar los servicios inyectados en el constructor de la startup aquí, por ejemplo:

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

public IConfiguration Configuration { get; }

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

Cualquier servicio registrado en ConfigureServices()puede ser inyectado en el Configure()método; Puede agregar un número arbitrario de servicios después del IApplicationBuilderparámetro:

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

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

Resolver dependencias manualmente

Si necesita resolver los servicios de forma manual, debe utilizar preferiblemente el ApplicationServicesproporcionado por IApplicationBuilderen el Configure()método:

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

Es posible pasar y usar directamente un IServiceProvideren el constructor de su Startupclase, pero como se indica arriba , contendrá un subconjunto limitado de servicios y, por lo tanto, tiene una utilidad limitada:

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

Si debe resolver los servicios en el ConfigureServices()método, se requiere un enfoque diferente. Puede crear un intermediario IServiceProviderdesde la IServiceCollectioninstancia que contiene los servicios que se han registrado hasta ese 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>();
}

Tenga en cuenta: en general, debe evitar resolver servicios dentro del ConfigureServices()método, ya que este es realmente el lugar donde está configurando los servicios de la aplicación. A veces solo necesitas acceder a una IOptions<MyOptions>instancia. Puede lograr esto vinculando los valores de la IConfigurationinstancia a una instancia de MyOptions(que es esencialmente lo que hace el marco de opciones):

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

La resolución manual de servicios (también conocido como Localizador de servicios) generalmente se considera un antipatrón . Si bien tiene sus casos de uso (para marcos y / o capas de infraestructura), debe evitarlo tanto como sea posible.

La resolución manual de instancias implica el uso de la IServiceProviderinterfaz:

Resolviendo dependencia en Startup.ConfigureServices

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

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

Resolver dependencias en el inicio.

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

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

    // ...
}

Resolver dependencias en el inicio.Configurar en ASP.NET Core 3

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

Uso de servicios inyectados en tiempo de ejecución

Algunos tipos se pueden inyectar 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)
    {
    }
}

Resolver dependencias en acciones del controlador

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

Si genera una aplicación con una plantilla, tendrá algo como esto en la Startupclase:

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

    services.AddMvc();
}

Luego puede agregar dependencias allí, por ejemplo:

services.AddTransient<ITestService, TestService>();

Si desea acceder ITestServiceen su controlador, puede agregar IServiceProviderel constructor y se inyectará:

public HomeController(IServiceProvider serviceProvider)

Luego puede resolver el servicio que agregó:

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

Tenga en cuenta que para usar la versión genérica debe incluir el espacio de nombres con las extensiones:

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();
        }

Si solo necesita resolver una dependencia con el fin de pasarla al constructor de otra dependencia que está registrando, puede hacerlo.

Digamos que tenía un servicio que incluía una cadena y un ISomeService.

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

Cuando vaya a registrar esto dentro de Startup.cs, deberá hacer esto:

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

Puede inyectar dependencias en atributos como AuthorizeAttribute de esta manera

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

Sé que esta es una vieja pregunta, pero me sorprende que no haya un truco bastante obvio y desagradable.

Puede aprovechar la capacidad de definir su propia función de ctor para tomar los valores necesarios de sus servicios a medida que los define ... obviamente, esto se ejecutará cada vez que se solicite el servicio a menos que elimine / borre explícitamente y vuelva a agregar la definición de Este servicio dentro de la primera construcción del ctor explotador .

Este método tiene la ventaja de no requerir que construya el árbol de servicios o que lo use durante la configuración del servicio. Todavía está definiendo cómo se configurarán los servicios.

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);
    });
}

La forma de arreglar este patrón sería dar OtherServiceuna dependencia explícita IServiceINeedToUse, en lugar de depender implícitamente de él o del valor de retorno de su método ... o resolver esa dependencia explícitamente de alguna otra manera.

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

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

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