Der lifetime einiger Dienste einschließlich DbContext kann folgendermaßen konfiguriert werden:
services.AddDbContext<ApplicationDbContext>(
options => { options.UseSqlServer("YourConnectionString"); },
ServiceLifetime.Singleton);
REF
Singleton-Scope ist eine sehr schlechte Idee für Ihren Kontext. Request-Scope ist das, was Sie verwenden sollten, da es im Wesentlichen ein Singleton für die Lebensdauer der Anfrage ist.
Warum Sie bei der Verwendung von Request-Scope Fehler erhalten, kann ich nicht mit Sicherheit sagen. Unter der Annahme, dass die von Ihnen verwendeten Entitäten alle aus demselben Kontexttyp stammen und dass Sie den Kontext überall dort korrekt einfügen, wo er benötigt wird, sollten niemals mehrere Kontextinstanzen im Spiel sein.
BEARBEITEN
Nachdem Sie Ihre Frage erneut gelesen haben, klingt es so, als würden Ihre Dienste tatsächlich den Kontext in ihren Konstruktoren oder so etwas initialisieren. Wenn dem so ist, ist das dein Problem. Ihr Kontext sollte in Ihre Dienste eingefügt werden, d. h.:
public class AccountService : IAccountService
{
protected readonly DbContext context;
public AccountService(DbContext context)
{
this.context = context;
}
...
}
Dann fügt Ninject die anfragebezogene Instanz von MyApplicationContext ordnungsgemäß ein wenn Sie einen der Dienste neu einrichten.
Dan, Sie erzeugen einen Engpass, wenn Sie einen einzelnen DBContext erfassen für die gesamte Bewerbung. Unter der Haube wird Entity Framework ziemlich effizient handhaben, wie viele Objekte Sie benötigen. Wenn Sie tiefer in die Interna einsteigen, tun die tatsächlichen Objekte, die die Datenbank kontaktieren, dasselbe. Ihr Versuch, durch Erstellen eines Singletons zu optimieren, kann also tatsächlich ein sehr großes Problem verursachen.