Meine typische .NET 4.5X-Webanwendungsstruktur besteht aus mindestens drei Ebenen: einem Webprojekt (eine .NET-Webanwendung), einem Domänen- / Geschäftslogikprojekt (eine Klassenbibliothek) und einem Datenzugriffsprojekt (eine Klassenbibliothek). . Das Webprojekt verweist auf die Business-Schicht und die Business-Schicht auf die Datenzugriffsschicht.

Ich mag diesen Ansatz, da mein Webprojekt keinen Verweis auf das Datenzugriffsprojekt hat (es muss zuerst die Domänen- / Geschäftslogikschicht durchlaufen). Mein Webprojekt sollte keinen Zugriff auf die Kontext- oder Repository-Klassen haben.

In der dreistufigen .net 4.5.X-App deklariere ich die Verbindungszeichenfolge in der web.config und gebe den Namen des DbContext als name-Attribut der Verbindungszeichenfolge an.

Im neuen Dotnet Core-Paradigma ist für jedes Beispiel, das ich sehe, der DbContext in der Datei Startup.cs folgendermaßen konfiguriert:

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddMvc();
    services.AddEntityFramework()
        .AddSqlServer()
        .AddDbContext<MyApplicationContext>("myconnectionstring  or reference to it");
}

Wenn Sie dem Start eine konkrete Klasse für den Datenbankkontext zuweisen, muss auf das Datenzugriffsprojekt verwiesen werden, in dem der Datenbankkontext definiert ist. Ich würde es vorziehen, nur auf die mittlere Ebene zu verweisen und den Verweis auf die DAL zu vermeiden.

Meine Frage lautet: Wie sollte ich meine Lösungsstruktur anordnen, damit ich nicht einen Verweis aus meinem Webprojekt zu meinem Datenzugriffsprojekt hinzufügen kann?

Kann ich eine Eigenschaft von appsettings.json verwenden?

Kann ich meine Entity-Konfiguration auf andere Weise hinzufügen?

Gibt es etwas Wichtiges, das mir am dot net core fehlt?

Danke im Voraus