Inserimento delle dipendenze in ASP.NET Core

Di Kirk Larkin, Steve Smith e Brandon Dahler

ASP.NET Core supporta il modello progettuale software per l'inserimento delle dipendenze, ovvero una tecnica per ottenere l'inversione del controllo (IoC) tra classi e relative dipendenze.

Per altre informazioni specifiche dell'inserimento delle dipendenze nei controller MVC, vedere Inserimento delle dipendenze nei controller in ASP.NET Core.

Per informazioni sull'uso dell'inserimento delle dipendenze nelle applicazioni diverse dalle app Web, vedere Inserimento delle dipendenze in .NET.

Per altre informazioni sull'inserimento di dipendenze di opzioni, vedere Modello di opzioni in ASP.NET Core.

Questo argomento fornisce informazioni sull'inserimento delle dipendenze in ASP.NET Core. La documentazione principale sull'uso dell'inserimento delle dipendenze è contenuta in Inserimento delle dipendenze in .NET.

Visualizzare o scaricare il codice di esempio (procedura per il download)

Panoramica dell'inserimento delle dipendenze

Una dipendenza è un oggetto da cui dipende un altro oggetto. Esaminare la classe MyDependency seguente con un metodo WriteMessage da cui dipendono altre classi:

public class MyDependency
{
    public void WriteMessage(string message)
    {
        Console.WriteLine($"MyDependency.WriteMessage called. Message: {message}");
    }
}

Una classe può creare un'istanza della classe MyDependency per usare il relativo metodo WriteMessage. Nell'esempio seguente la classe MyDependency è una dipendenza della classe IndexModel:

public class IndexModel : PageModel
{
    private readonly MyDependency _dependency = new MyDependency();

    public void OnGet()
    {
        _dependency.WriteMessage("IndexModel.OnGet");
    }
}

La classe crea e dipende direttamente dalla classe MyDependency. Le dipendenze del codice, ad esempio nell'esempio precedente, sono problematiche e devono essere evitate per i motivi seguenti:

• Per sostituire MyDependency con un'implementazione diversa, la classe IndexModel deve essere modificata.
• Se MyDependency presenta delle dipendenze, devono essere configurate anche dalla classe IndexModel. In un progetto di grandi dimensioni con più classi che dipendono da MyDependency, il codice di configurazione diventa sparso in tutta l'app.
• È difficile eseguire unit test di questa implementazione.

L'inserimento delle dipendenze consente di risolvere questi problemi tramite:

• L'uso di un'interfaccia o di una classe di base per astrarre l'implementazione delle dipendenze.
• La registrazione della dipendenza in un contenitore di servizi. ASP.NET Core offre il contenitore di servizi predefinito IServiceProvider. I servizi vengono in genere registrati nel file dell'app Program.cs .
• L'inserimento del servizio nel costruttore della classe in cui viene usato. Il framework si assume la responsabilità della creazione di un'istanza della dipendenza e della sua eliminazione quando non è più necessaria.

Nell'app di esempio l'interfaccia IMyDependencydefinisce il WriteMessage metodo :

public interface IMyDependency
{
    void WriteMessage(string message);
}

Questa interfaccia viene implementata da un tipo concreto, MyDependency:

public class MyDependency : IMyDependency
{
    public void WriteMessage(string message)
    {
        Console.WriteLine($"MyDependency.WriteMessage Message: {message}");
    }
}

L'app di esempio registra il IMyDependency servizio con il tipo MyDependencyconcreto . Il AddScoped metodo registra il servizio con una durata con ambito, ovvero la durata di una singola richiesta. Le durate dei servizi sono descritte più avanti in questo argomento.

using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddScoped<IMyDependency, MyDependency>();

var app = builder.Build();

Nell'app di esempio, il IMyDependency servizio viene richiesto e usato per chiamare il WriteMessage metodo :

public class Index2Model : PageModel
{
    private readonly IMyDependency _myDependency;

    public Index2Model(IMyDependency myDependency)
    {
        _myDependency = myDependency;            
    }

    public void OnGet()
    {
        _myDependency.WriteMessage("Index2Model.OnGet");
    }
}

Usando il modello di inserimento delle dipendenze, il controller o Razor la pagina:

• Non usa il tipo MyDependencyconcreto , solo l'interfaccia IMyDependency implementata. In questo modo è facile modificare l'implementazione senza modificare il controller o Razor la pagina.
• Non crea un'istanza di MyDependency, viene creata dal contenitore di inserimento delle dipendenze.

L'implementazione dell'interfaccia IMyDependency può essere migliorata usando l'API di registrazione predefinita:

public class MyDependency2 : IMyDependency
{
    private readonly ILogger<MyDependency2> _logger;

    public MyDependency2(ILogger<MyDependency2> logger)
    {
        _logger = logger;
    }

    public void WriteMessage(string message)
    {
        _logger.LogInformation( $"MyDependency2.WriteMessage Message: {message}");
    }
}

L'aggiornamento Program.cs registra la nuova IMyDependency implementazione:

using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddScoped<IMyDependency, MyDependency2>();

var app = builder.Build();

MyDependency2 dipende da ILogger<TCategoryName>, che viene richiesto nel costruttore. ILogger<TCategoryName> è un servizio fornito dal framework.

Non è insolito usare l'inserimento delle dipendenze in modo concatenato. Ogni dipendenza richiesta richiede a sua volta le proprie dipendenze. Il contenitore risolve le dipendenze nel grafico e restituisce il servizio completamente risolto. Il set di dipendenze che devono essere risolte viene generalmente chiamato albero delle dipendenze o grafico dipendenze o grafico degli oggetti.

Il contenitore risolve ILogger<TCategoryName> avvalendosi dei tipi aperti (generici), eliminando la necessità di registrare ogni tipo costruito (generico).

Nella terminologia di inserimento delle dipendenze, un servizio:

• In genere è un oggetto che fornisce un servizio ad altri oggetti, ad esempio il servizio IMyDependency.
• Non è correlato a un servizio Web, anche se il servizio può usare un servizio Web.

Il framework fornisce un sistema di registrazione affidabile. Le implementazioni IMyDependency illustrate negli esempi precedenti sono state scritte per illustrare l'inserimento delle dipendenze di base, non per implementare la registrazione. La maggior parte delle app non deve scrivere logger. Il codice seguente illustra l'uso della registrazione predefinita, che non richiede la registrazione di alcun servizio:

public class AboutModel : PageModel
{
    private readonly ILogger _logger;

    public AboutModel(ILogger<AboutModel> logger)
    {
        _logger = logger;
    }
    
    public string Message { get; set; } = string.Empty;

    public void OnGet()
    {
        Message = $"About page visited at {DateTime.UtcNow.ToLongTimeString()}";
        _logger.LogInformation(Message);
    }
}

Usando il codice precedente, non è necessario aggiornare Program.cs, perché la registrazione viene fornita dal framework.

Registrare gruppi di servizi con metodi di estensione

Il framework ASP.NET Core usa una convenzione per la registrazione di un gruppo di servizi correlati. La convenzione consiste nell'usare un singolo metodo di estensione Add{GROUP_NAME} per registrare tutti i servizi richiesti da una funzionalità del framework. Ad esempio, il AddControllers metodo di estensione registra i servizi necessari per i controller MVC.

Il codice seguente viene generato dal Razor modello Pages usando singoli account utente e illustra come aggiungere altri servizi al contenitore usando i metodi AddDbContext di estensione e AddDefaultIdentity:

using DependencyInjectionSample.Data;
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();

builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();

var app = builder.Build();

Considerare il codice seguente che registra i servizi e configura le opzioni:

using ConfigSample.Options;
using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.Configure<PositionOptions>(
    builder.Configuration.GetSection(PositionOptions.Position));
builder.Services.Configure<ColorOptions>(
    builder.Configuration.GetSection(ColorOptions.Color));

builder.Services.AddScoped<IMyDependency, MyDependency>();
builder.Services.AddScoped<IMyDependency2, MyDependency2>();

var app = builder.Build();

I gruppi correlati di registrazioni possono essere spostati in un metodo di estensione per registrare i servizi. Ad esempio, i servizi di configurazione vengono aggiunti alla classe seguente:

using ConfigSample.Options;
using Microsoft.Extensions.Configuration;

namespace Microsoft.Extensions.DependencyInjection
{
    public static class MyConfigServiceCollectionExtensions
    {
        public static IServiceCollection AddConfig(
             this IServiceCollection services, IConfiguration config)
        {
            services.Configure<PositionOptions>(
                config.GetSection(PositionOptions.Position));
            services.Configure<ColorOptions>(
                config.GetSection(ColorOptions.Color));

            return services;
        }

        public static IServiceCollection AddMyDependencyGroup(
             this IServiceCollection services)
        {
            services.AddScoped<IMyDependency, MyDependency>();
            services.AddScoped<IMyDependency2, MyDependency2>();

            return services;
        }
    }
}

I servizi rimanenti vengono registrati in una classe simile. Il codice seguente usa i nuovi metodi di estensione per registrare i servizi:

using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddConfig(builder.Configuration)
    .AddMyDependencyGroup();

builder.Services.AddRazorPages();

var app = builder.Build();

Nota: ogni metodo di estensione services.Add{GROUP_NAME} aggiunge e configura potenzialmente i servizi. Ad esempio, AddControllersWithViews aggiunge i controller MVC dei servizi con visualizzazioni richiesti e AddRazorPages aggiunge le pagina Razor dei servizi richieste.

Durate del servizio

Vedere Durata del servizio in Inserimento delle dipendenze in .NET

Per usare i servizi con ambito nel middleware, usare uno degli approcci seguenti:

• Inserire il servizio nel metodo o InvokeAsync del Invoke middleware. L'uso dell'inserimento del costruttore genera un'eccezione di runtime perché forza il comportamento del servizio con ambito come un singleton. L'esempio nella sezione Opzioni di durata e registrazione illustra l'approccio InvokeAsync .
• Usare il middleware basato su factory. Il middleware registrato con questo approccio viene attivato per ogni richiesta client (connessione), che consente l'inserimento di servizi con ambito nel costruttore del middleware.

Per altre informazioni, vedere Scrivere middleware personalizzato ASP.NET Core.

Metodi di registrazione del servizio

Vedere Metodi di registrazione del servizio in Inserimento delle dipendenze in .NET

È comune usare più implementazioni quando si simulano i tipi per i test.

La registrazione di un servizio con solo un tipo di implementazione equivale alla registrazione del servizio con lo stesso tipo di implementazione e di servizio. Ecco perché non è possibile registrare più implementazioni di un servizio usando i metodi che non accettano un tipo di servizio esplicito. Questi metodi possono registrare più istanze di un servizio, ma avranno tutti lo stesso tipo di implementazione.

Uno dei metodi di registrazione del servizio precedenti può essere usato per registrare più istanze del servizio dello stesso tipo di servizio. Nell'esempio seguente AddSingleton viene chiamato due volte con IMyDependency come tipo di servizio. La seconda chiamata a AddSingleton esegue l'override di quella precedente quando viene risolta come IMyDependency e si aggiunge a quella precedente quando più servizi vengono risolti tramite IEnumerable<IMyDependency>. I servizi vengono visualizzati nell'ordine in cui sono stati registrati quando sono stati risolti tramite IEnumerable<{SERVICE}>.

services.AddSingleton<IMyDependency, MyDependency>();
services.AddSingleton<IMyDependency, DifferentDependency>();

public class MyService
{
    public MyService(IMyDependency myDependency, 
       IEnumerable<IMyDependency> myDependencies)
    {
        Trace.Assert(myDependency is DifferentDependency);

        var dependencyArray = myDependencies.ToArray();
        Trace.Assert(dependencyArray[0] is MyDependency);
        Trace.Assert(dependencyArray[1] is DifferentDependency);
    }
}

Servizi con chiave

I servizi con chiave fanno riferimento a un meccanismo per la registrazione e il recupero di servizi di inserimento delle dipendenze tramite chiavi. Un servizio è associato a una chiave chiamando AddKeyedSingleton (o AddKeyedScoped ) AddKeyedTransientper registrarlo. Accedere a un servizio registrato specificando la chiave con l'attributo [FromKeyedServices] . Il codice seguente illustra come usare i servizi con chiave:

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.SignalR;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddKeyedSingleton<ICache, BigCache>("big");
builder.Services.AddKeyedSingleton<ICache, SmallCache>("small");
builder.Services.AddControllers();

var app = builder.Build();

app.MapGet("/big", ([FromKeyedServices("big")] ICache bigCache) => bigCache.Get("date"));
app.MapGet("/small", ([FromKeyedServices("small")] ICache smallCache) =>
                                                               smallCache.Get("date"));

app.MapControllers();

app.Run();

public interface ICache
{
    object Get(string key);
}
public class BigCache : ICache
{
    public object Get(string key) => $"Resolving {key} from big cache.";
}

public class SmallCache : ICache
{
    public object Get(string key) => $"Resolving {key} from small cache.";
}

[ApiController]
[Route("/cache")]
public class CustomServicesApiController : Controller
{
    [HttpGet("big-cache")]
    public ActionResult<object> GetOk([FromKeyedServices("big")] ICache cache)
    {
        return cache.Get("data-mvc");
    }
}

public class MyHub : Hub
{
    public void Method([FromKeyedServices("small")] ICache cache)
    {
        Console.WriteLine(cache.Get("signalr"));
    }
}

Comportamento dell'inserimento del costruttore

Vedere Comportamento di inserimento del costruttore in Inserimento delle dipendenze in .NET

Contesti di Entity Framework

Per impostazione predefinita, i contesti di Entity Framework vengono aggiunti al contenitore del servizio usando la durata con ambito perché le operazioni del database dell'app Web sono in genere limitati alla richiesta client. Per usare una durata diversa, specificare la durata usando un AddDbContext overload. I servizi di una determinata durata non devono usare un contesto di database con una durata inferiore alla durata del servizio.

Opzioni di durata e di registrazione

Per illustrare la differenza tra la durata del servizio e le relative opzioni di registrazione, considerare le interfacce seguenti che rappresentano un'attività come operazione con un identificatore , OperationId. A seconda del modo in cui viene configurata la durata del servizio di un'operazione per le interfacce seguenti, il contenitore fornisce le stesse istanze o diverse del servizio quando richiesto da una classe:

public interface IOperation
{
    string OperationId { get; }
}

public interface IOperationTransient : IOperation { }
public interface IOperationScoped : IOperation { }
public interface IOperationSingleton : IOperation { }

La classe seguente Operation implementa tutte le interfacce precedenti. Il Operation costruttore genera un GUID e archivia gli ultimi 4 caratteri nella OperationId proprietà :

public class Operation : IOperationTransient, IOperationScoped, IOperationSingleton
{
    public Operation()
    {
        OperationId = Guid.NewGuid().ToString()[^4..];
    }

    public string OperationId { get; }
}

Il codice seguente crea più registrazioni della Operation classe in base alle durate denominate:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddTransient<IOperationTransient, Operation>();
builder.Services.AddScoped<IOperationScoped, Operation>();
builder.Services.AddSingleton<IOperationSingleton, Operation>();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseMyMiddleware();
app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

L'app di esempio illustra la durata degli oggetti sia all'interno che tra le richieste. E IndexModel il middleware richiedono ogni tipo di IOperation tipo e registrano per OperationId ognuno di essi:

public class IndexModel : PageModel
{
    private readonly ILogger _logger;
    private readonly IOperationTransient _transientOperation;
    private readonly IOperationSingleton _singletonOperation;
    private readonly IOperationScoped _scopedOperation;

    public IndexModel(ILogger<IndexModel> logger,
                      IOperationTransient transientOperation,
                      IOperationScoped scopedOperation,
                      IOperationSingleton singletonOperation)
    {
        _logger = logger;
        _transientOperation = transientOperation;
        _scopedOperation    = scopedOperation;
        _singletonOperation = singletonOperation;
    }

    public void  OnGet()
    {
        _logger.LogInformation("Transient: " + _transientOperation.OperationId);
        _logger.LogInformation("Scoped: "    + _scopedOperation.OperationId);
        _logger.LogInformation("Singleton: " + _singletonOperation.OperationId);
    }
}

Analogamente a IndexModel, il middleware risolve gli stessi servizi:

public class MyMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger _logger;

    private readonly IOperationSingleton _singletonOperation;

    public MyMiddleware(RequestDelegate next, ILogger<MyMiddleware> logger,
        IOperationSingleton singletonOperation)
    {
        _logger = logger;
        _singletonOperation = singletonOperation;
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context,
        IOperationTransient transientOperation, IOperationScoped scopedOperation)
    {
        _logger.LogInformation("Transient: " + transientOperation.OperationId);
        _logger.LogInformation("Scoped: " + scopedOperation.OperationId);
        _logger.LogInformation("Singleton: " + _singletonOperation.OperationId);

        await _next(context);
    }
}

public static class MyMiddlewareExtensions
{
    public static IApplicationBuilder UseMyMiddleware(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<MyMiddleware>();
    }
}

I servizi con ambito e temporanei devono essere risolti nel InvokeAsync metodo :

public async Task InvokeAsync(HttpContext context,
    IOperationTransient transientOperation, IOperationScoped scopedOperation)
{
    _logger.LogInformation("Transient: " + transientOperation.OperationId);
    _logger.LogInformation("Scoped: " + scopedOperation.OperationId);
    _logger.LogInformation("Singleton: " + _singletonOperation.OperationId);

    await _next(context);
}

L'output del logger mostra:

• Gli oggetti temporanei sono sempre diversi. Il valore temporaneo OperationId è diverso in IndexModel e nel middleware.
• Gli oggetti con ambito sono gli stessi per una determinata richiesta, ma differiscono per ogni nuova richiesta.
• Gli oggetti Singleton sono gli stessi per ogni richiesta.

Per ridurre l'output della registrazione, impostare "Logging:LogLevel:Microsoft:Error" nel appsettings.Development.json file:

{
  "MyKey": "MyKey from appsettings.Developement.json",
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "System": "Debug",
      "Microsoft": "Error"
    }
  }
}

Risolvere un servizio all'avvio dell'app

Il codice seguente illustra come risolvere un servizio con ambito per una durata limitata all'avvio dell'app:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<IMyDependency, MyDependency>();

var app = builder.Build();

using (var serviceScope = app.Services.CreateScope())
{
    var services = serviceScope.ServiceProvider;

    var myDependency = services.GetRequiredService<IMyDependency>();
    myDependency.WriteMessage("Call services from main");
}

app.MapGet("/", () => "Hello World!");

app.Run();

Convalida dell'ambito

Vedere Comportamento di inserimento del costruttore in Inserimento delle dipendenze in .NET

Per ulteriori informazioni, vedere Convalida dell'ambito.

Servizi di richiesta

I servizi e le relative dipendenze all'interno di una richiesta core ASP.NET vengono esposti tramite HttpContext.RequestServices.

Il framework crea un ambito per richiesta ed RequestServices espone il provider di servizi con ambito. Tutti i servizi con ambito sono validi fino a quando la richiesta è attiva.

Nota

Preferire la richiesta di dipendenze come parametri del costruttore rispetto alla risoluzione dei servizi da RequestServices. La richiesta di dipendenze come parametri del costruttore produce classi che sono più facili da testare.

Progettare i servizi per l'inserimento di dipendenze

Quando si progettano servizi per l'inserimento delle dipendenze:

• Evitare classi e membri statici con stato. Evitare di creare uno stato globale progettando invece le app per l'uso dei servizi singleton.
• Evitare la creazione diretta di istanze delle classi dipendenti all'interno di servizi. La creazione diretta di istanze associa il codice a una determinata implementazione.
• Rendere i servizi di dimensioni ridotte, ben fattorizzati e facili da testare.

Se una classe ha molte dipendenze inserite, potrebbe essere un segno che la classe ha troppe responsabilità e viola il principio di responsabilità singola (SRP). Tentare di effettuare il refactoring della classe spostando alcune delle responsabilità in nuove classi. Tenere presente che Razor le classi del modello di pagina Pages e le classi di controller MVC devono concentrarsi sulle problematiche dell'interfaccia utente.

Eliminazione dei servizi

Il contenitore chiama Dispose per i tipi IDisposable creati. I servizi risolti dal contenitore non devono mai essere eliminati dallo sviluppatore. Se un tipo o una factory viene registrato come singleton, il contenitore elimina automaticamente il singleton.

Nell'esempio seguente i servizi vengono creati dal contenitore del servizio ed eliminati automaticamente: dependency-injection\samples\6.x\DIsample2\DIsample2\Services\Service1.cs

public class Service1 : IDisposable
{
    private bool _disposed;

    public void Write(string message)
    {
        Console.WriteLine($"Service1: {message}");
    }

    public void Dispose()
    {
        if (_disposed)
            return;

        Console.WriteLine("Service1.Dispose");
        _disposed = true;
    }
}

public class Service2 : IDisposable
{
    private bool _disposed;

    public void Write(string message)
    {
        Console.WriteLine($"Service2: {message}");
    }

    public void Dispose()
    {
        if (_disposed)
            return;

        Console.WriteLine("Service2.Dispose");
        _disposed = true;
    }
}

public interface IService3
{
    public void Write(string message);
}

public class Service3 : IService3, IDisposable
{
    private bool _disposed;

    public Service3(string myKey)
    {
        MyKey = myKey;
    }

    public string MyKey { get; }

    public void Write(string message)
    {
        Console.WriteLine($"Service3: {message}, MyKey = {MyKey}");
    }

    public void Dispose()
    {
        if (_disposed)
            return;

        Console.WriteLine("Service3.Dispose");
        _disposed = true;
    }
}

using DIsample2.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddScoped<Service1>();
builder.Services.AddSingleton<Service2>();

var myKey = builder.Configuration["MyKey"];
builder.Services.AddSingleton<IService3>(sp => new Service3(myKey));

var app = builder.Build();

public class IndexModel : PageModel
{
    private readonly Service1 _service1;
    private readonly Service2 _service2;
    private readonly IService3 _service3;

    public IndexModel(Service1 service1, Service2 service2, IService3 service3)
    {
        _service1 = service1;
        _service2 = service2;
        _service3 = service3;
    }

    public void OnGet()
    {
        _service1.Write("IndexModel.OnGet");
        _service2.Write("IndexModel.OnGet");
        _service3.Write("IndexModel.OnGet");
    }
}

La console di debug mostra l'output seguente dopo ogni aggiornamento della pagina Indice:

Service1: IndexModel.OnGet
Service2: IndexModel.OnGet
Service3: IndexModel.OnGet, MyKey = MyKey from appsettings.Developement.json
Service1.Dispose

Servizi non creati dal contenitore del servizio

Osservare il codice seguente:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddSingleton(new Service1());
builder.Services.AddSingleton(new Service2());

Nel codice precedente:

• Le istanze del servizio non vengono create dal contenitore del servizio.
• Il framework non elimina automaticamente i servizi.
• Lo sviluppatore è responsabile dell'eliminazione dei servizi.

Indicazioni IDisposable per le istanze temporanee e condivise

Vedere Linee guida IDisposable per l'istanza temporanea e condivisa in Inserimento delle dipendenze in .NET

Sostituzione del contenitore di servizi predefinito

Vedere Sostituzione predefinita del contenitore del servizio in Inserimento delle dipendenze in .NET

Consigli

Vedere Consigli in Inserimento delle dipendenze in .NET

• Evitare di usare il modello di localizzatore del servizio. Ad esempio, non richiamare GetService per ottenere un'istanza del servizio quando è invece possibile usare l'inserimento delle dipendenze:

  Risposta errata:

  

  Risposta corretta:

  public class MyClass
  {
      private readonly IOptionsMonitor<MyOptions> _optionsMonitor;
  
      public MyClass(IOptionsMonitor<MyOptions> optionsMonitor)
      {
          _optionsMonitor = optionsMonitor;
      }
  
      public void MyMethod()
      {
          var option = _optionsMonitor.CurrentValue.Option;
  
          ...
      }
  }
  

• Un'altra variazione del localizzatore del servizio da evitare è inserire una factory che risolve le dipendenze in fase di esecuzione. Queste procedure combinano le strategie di inversione del controllo.

• Evitare l'accesso statico a HttpContext (ad esempio IHttpContextAccessor.HttpContext).

L'inserimento di dipendenze è un'alternativa ai modelli di accesso agli oggetti statici/globali. Se l'inserimento di dipendenze viene usato con l'accesso agli oggetti statico i vantaggi non saranno evidenti.

Modelli consigliati per la multi-tenancy nell'inserimento delle dipendenze

Orchard Core è un framework applicativo per la creazione di applicazioni modulari multi-tenant in ASP.NET Core. Per altre informazioni, vedere la documentazione di Orchard Core.

Vedere gli esempi di Orchard Core per esempi di come creare app modulari e multi-tenant usando solo Orchard Core Framework senza alcuna funzionalità specifica di CMS.

Servizi forniti dal framework

Program.cs registra i servizi usati dall'app, incluse le funzionalità della piattaforma, ad esempio Entity Framework Core e ASP.NET Core MVC. Inizialmente, l'oggetto IServiceCollection fornito a Program.cs ha servizi definiti dal framework a seconda della modalità di configurazione dell'host. Per le app basate sui modelli ASP.NET Core, il framework registra più di 250 servizi.

La tabella seguente elenca un piccolo esempio di questi servizi registrati dal framework:

Tipo di servizio	Durata
Microsoft.AspNetCore.Hosting.Builder.IApplicationBuilderFactory	Temporaneo
IHostApplicationLifetime	Singleton
IWebHostEnvironment	Singleton
Microsoft.AspNetCore.Hosting.IStartup	Singleton
Microsoft.AspNetCore.Hosting.IStartupFilter	Temporaneo
Microsoft.AspNetCore.Hosting.Server.IServer	Singleton
Microsoft.AspNetCore.Http.IHttpContextFactory	Temporaneo
Microsoft.Extensions.Logging.ILogger<TCategoryName>	Singleton
Microsoft.Extensions.Logging.ILoggerFactory	Singleton
Microsoft.Extensions.ObjectPool.ObjectPoolProvider	Singleton
Microsoft.Extensions.Options.IConfigureOptions<TOptions>	Temporaneo
Microsoft.Extensions.Options.IOptions<TOptions>	Singleton
System.Diagnostics.DiagnosticSource	Singleton
System.Diagnostics.DiagnosticListener	Singleton

Risorse aggiuntive

• Inserimento di dipendenze in viste in ASP.NET Core
• Inserimento delle dipendenze nei controller in ASP.NET Core
• Inserimento delle dipendenze nei gestori dei requisiti in ASP.NET Core
• ASP.NET core Blazor dependency injection
• Modelli di conferenza NDC per lo sviluppo di app di inserimento delle dipendenze
• Avvio dell'app in ASP.NET Core
• Attivazione middleware basata su factory in ASP.NET Core
• ASP.NET CORE DEPENDENCY INJECTION: CHE COS'È L'I edizione Standard RVICECOLLECTION?
• Quattro modi per eliminare IDisposable in ASP.NET Core
• Scrittura di codice pulito in ASP.NET Core con inserimento delle dipendenze (MSDN)
• Explicit Dependencies Principle (Principio delle dipendenze esplicite)
• Inversion of Control Containers and the Dependency Injection Pattern (Martin Fowler) (Contenitori di inversione del controllo e modello di inserimento delle dipendenze)
• How to register a service with multiple interfaces in ASP.NET Core DI (Come registrare un servizio con più interfacce in ASP.NET Core DI)