Wann sollte ich Datenkontexte in LINQ to SQL entsorgen?

Wann sollten Datenkontexte entsorgt werden?

In Datenzugriffsschichten, die LINQ-Klassen verwenden, stößt man häufig auf die Frage der Verwaltung von Datenkontexten. Betrachten wir den folgenden Codeausschnitt:

private DataContext myDb;
public static MyClass GetMyClassById(int id)
{
    DataContext db = new DataContext();
    MyClass result = (from item in db.MyClasss
                      where item.id == id
                      select item).Single();
    result.myDb = db;
    return result;
}

public void Save()
{
    db.SubmitChanges();
}

Dieses Muster wirft Fragen zur Instanziierung von Datenkontexten und der Notwendigkeit ihrer Entsorgung auf. Um dieses Problem anzugehen, haben wir Matt Warren vom LINQ to SQL-Team um Rat gefragt.

Laut Warren dient die Implementierung von IDisposable mehreren Zwecken:

• Durchsetzung des Vertrags: IDisposable ermöglicht die Durchsetzung des Vertrags, dass Entitäten nur dann über die erwartete Nutzung des DataContext hinaus gehalten werden können, wenn Dispose vorhanden ist aufgerufen.
• Cache leeren: Dispose zwingt den DataContext, seinen Cache von materialisierten Entitäten zu löschen, wodurch eine unbeabsichtigte Beibehaltung aller Entitäten durch eine einzelne zwischengespeicherte Entität verhindert wird.
• Schließen von Verbindungen: Während der DataContext Verbindungen automatisch schließt, können bestimmte Umstände diesen Prozess beeinträchtigen. Dispose bietet in solchen Fällen eine Problemumgehung.

Warren betonte, dass die Entsorgung von DataContexts in den meisten Fällen nicht unbedingt erforderlich ist. Aus Gründen der Konsistenz und Klarheit ist es jedoch häufig vorzuziehen, alle Objekte zu entsorgen, die IDisposable implementieren.

Das obige ist der detaillierte Inhalt vonWann sollte ich Datenkontexte in LINQ to SQL entsorgen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!