DbContext für Hintergrundaufgaben über Dependency Injection

Question

Ich denke wahrscheinlich nicht in die richtige Richtung. Ich bin ziemlich neu in Dependency Injection und ASP.Net Core.

Ich habe eine ASP.Net Core-Website, und eine der Aufgaben besteht darin, Daten aus einem Excel-Blatt in eine Datenbank zu importieren, die ein Benutzer hochladen wird. Die Excel-Tabellen können riesig sein, und die Datentransformationsaufgaben sind zeitaufwendig, daher möchte ich sie im Hintergrund ausführen. h. Der Benutzer lädt das Blatt hoch, die Antwort wird sofort gesendet und der Hintergrund-Job/Thread importiert die Daten.

Ich versuche, den Hintergrund-Job von laufen:

Task.Run(() => ProcessImport(model)); 

Das Problem, das ich laufen in ist, dass der Prozess Importmethode Dienste aufruft, die die AppDbContext über ASP.Net Dependency Injection Container Zugriff auf die Repository-Klassen ist als Scoped hinzugefügt und sobald die Antwort zurückgeschickt wird, wird der Kontext entsorgt. Ich bekomme eine Laufzeitausnahme, dass Sie einen Kontext nicht verwenden können, nachdem es entsorgt wurde.

Meine Frage ist, was ist der beste Weg, um mit dieser Situation umzugehen? Soll ich den AppDbContext Singleton machen? Soll ich eine neue Instanz von AppDbContext in der ProcessImport-Methode erstellen und weitergeben? Ich habe DbContext gelesen ist Thread nicht sicher, also ist das ein guter Ansatz?

Answer 1

Sie sollten IServiceScopeFactory Instanz (es ist Singleton) in Ihre Aufgabe übergeben.

Innerhalb Aufgabe, wenn Daten ankommen, sollten Sie neue CreateScope() erstellen und Dienste aus diesem Bereich anfordern. Wenn der Datenprozess abgeschlossen ist, entfernen Sie diesen Bereich (aber halten Sie für den nächsten Lauf den Verweis auf IServiceScopeFactory).

Siehe zum Beispiel this. Ich leite kleine und schnelle Aufgaben mit dieser Bibliothek.

Für schwere/lange laufende Aufgaben, wie Gert schrieb, verlassen Sie sich nicht darauf, dass Ihre Aufgabe immer vollständig ausgeführt wird. Seien Sie bereit für den Neustart, seien Sie bereit für die erneute Verarbeitung der gleichen Daten.

Answer 2

Zum Abbau Ihre Fragen:

1. was ist der beste Weg, um diese Situation zu bewältigen?

   Es ist nicht ideal, dass die API die lang andauernden Aufgaben bewältigt. Sie können den Prozess an eine Hintergrundanwendung delegieren

2. Sollte ich den AppDbContext Singleton machen?

   Der dbContext sollte in einem Webanwendungsszenario nicht Singleton sein, da dies Probleme wie die Verwaltung von Transaktionen darstellen kann.

3. Was ist der beste Weg, um mit dieser Situation umzugehen?

   Aufschlüsselung der verschiedenen Dienste/Prozess:

   • Die API, die eine Datei nehmen. Im Idealfall sollte die API die Datei nur als Eingabe nehmen und auf der Festplatte oder in der Datenbank speichern.
   • Ein Dienst, der die Datei verarbeitet. Erstellen Sie diese Komponente/diesen Dienst als separate Bibliothek. Dann konsumiere diese Bibliothek von einer Konsolen-App. Auf diese Weise können Sie die Leistung profilieren. Machen Sie es zum Feuern und vergessen Sie die Methode, indem Sie es als asynchrone Methode verwenden.Auf diese Weise haben Sie die Flexibilität, Ihren Code wiederzuverwenden.
   • Wenn Sie nicht viele Dateiuploads erwarten, können Sie die Bibliothek auf Ihrem API-Controller wiederverwenden und die Methode mit QueueBackgroundWorkItem ausführen. Siehe hier als Referenz: http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx

4. Soll ich eine neue Instanz von AppDbContext im ProcessImport Methode erstellen, und übergibt es an?

   Da es nicht Thread-sicher ist, erstellen und verwenden Sie in jedem Thread eine separate Instanz Ihrer dbContext-Klasse.

5. Ich habe gelesen DbContext ist nicht threadsicher, also ist das ein guter Ansatz?

   Für eine ausführliche Anleitung von EF DbContext mit, Check-out in diesem Blog: "Soll ich die AppDbContext Singleton machen" http://mehdi.me/ambient-dbcontext-in-ef6/