Ich habe es verstanden, indem ich mir dieses Video mit Rowan Miller angesehen habehttps: //channel9.msdn.com/Series/Whats-New-with-ASPNET-5/0 (in Minute 22) dass die Möglichkeit zum Konfigurieren von Entity Framework Core (zuvor als EF7 bezeichnet) in einer ASP.NET Core 1.0-App (zuvor als ASP.NET 5 bezeichnet) inStartup.cs ist wie folgt

    public void ConfigureServices(IServiceCollection services)
    {
        //Entity Framework 7 scoped per request??
        services.AddEntityFramework()
            .AddSqlServer()
            .AddDbContext<MyDbContext>(options =>
            {
                options
                  .UseSqlServer(Configuration["Data:DefaultConnection:ConnectionString"]);
            });

        //MVC 6
        services.AddMvc();
    }

und dasdieser DbContext wird auf eine http-Anfrage begrenzt Wenn also im Code der gesamten http-Pipeline (einschließlich Middleware oder MVC) ein DbContext verwendet wird, wissen wir, dass die vom DI-Container injizierte Instanz dieselbe ist.

Aber das Problem ist, dass es nicht so zu funktionieren scheint. Innerhalb der Lebensdauer von MVC stimmt es, dass die injizierte DbContext-Instanz dieselbe ist, jedoch wie hier beschrieben:Entity Framework Core 1.0 Arbeitseinheit mit Asp.Net Core-Middleware oder Mvc-Filter Ich versuche, die folgende Middleware in die Pipeline zu stecken, um eine Art zentrales Commit / Rollback zu erreichen, nachdem ein Controller die Ausführung abgeschlossen hat:

public class UnitOfWorkMiddleware
{
    private readonly RequestDelegate _next;
    private readonly MyDbContext _dbContext;
    private readonly ILogger _logger;

    public UnitOfWorkMiddleware(RequestDelegate next, MyDbContext dbContext, ILoggerFactory loggerFactory)
    {
        _next = next;
        _dbContext = dbContext;
        _logger = loggerFactory.CreateLogger<UnitOfWorkMiddleware>();
    }

    public async Task Invoke(HttpContext httpContext)
    {
        await _next.Invoke(httpContext);
        _logger.LogInformation("Saving changes for unit of work if everything went good");
        await _dbContext.SaveChangesAsync();
    }
}

und diese Middleware ist unmittelbar vor MVC6 in der Pipeline

//inside Configure(IApplicationBuilder app) in Startup.cs
app.UseMiddleware<UnitOfWorkMiddleware>();
app.UseMvcWithDefaultRoute();

Die DbContext-Instanz in meiner Middleware stimmt nicht mit der Instanz überein, die während der MVC-Lebensdauer injiziert wird..

Ist das zu erwarten? Sollte ein DbContext nicht auf eine http-Anfrage beschränkt sein? Ist es möglich zu erreichen, was ich erreichen wollte?

Der Plan B wäre, ein @ zu verwendMVC 6 Globaler Filter (wenn ich eine Dokumentation dazu finden kann). Ich gehe davon aus, dass als Teil des MVC 6-Frameworks die injizierte DbContext-Instanz dieselbe sein wird.