LinqToSql DataContext statici in un'applicazione web

Question

In un'applicazione web che ho eseguito in tutto, ho trovato il seguente codice a che fare con il DataContext quando si tratta di LinqToSQL

public partial class DbDataContext 
    { 
    public static DbDataContext DB 
    { 
     get 
     { 
     if (HttpContext.Current.Items["DB"] == null) 
      HttpContext.Current.Items["DB"] = new DbDataContext(); 
     return (DbDataContext)HttpContext.Current.Items["DB"]; 
     } 
    } 
    } 

Poi fa riferimento in un secondo momento facendo questo:

DbDataContext.DB.Accounts.Single(a => a.accountId == accountId).guid = newGuid; 
DbDataContext.DB.SubmitChanges(); 

Sono stato a esaminare le migliori pratiche quando si tratta di LinqToSQL.

Non sono sicuro dell'approccio adottato da Microsoft quando si tratta di DataContext che non è ThreadSafe e ne conserva una copia statica.

Si tratta di un buon approccio per l'applicazione Web?

@ Longhorn213 - In base a ciò che hai detto e più ho letto in HttpContext a causa di ciò, penso che tu abbia ragione. Ma nell'applicazione che ho ereditato è confuso perché all'inizio di ogni metodo stanno requisendo il db per ottenere le informazioni, quindi modificare quell'istanza del datacontext e inviare le modifiche su di esso.

Da questo, penso che questo metodo dovrebbe essere scoraggiato perché dà la falsa impressione che il datacontext sia statico e persistente tra le richieste. Se un futuro sviluppatore pensa che la richiesta dei dati all'inizio di un metodo sia perché pensano che sia già presente, potrebbero incorrere in problemi e non capire perché.

Quindi credo che la mia domanda sia, dovrebbe essere scoraggiato questo metodo nello sviluppo futuro?

Answer 1

Questa non è una copia statica. Si noti che la proprietà lo recupera da Context.Items, che è per richiesta. Questa è una copia per richiesta del DataContext, accessibile tramite una proprietà statica.

D'altra parte, questa proprietà presuppone solo un singolo thread per richiesta, che potrebbe non essere vero per sempre.

Answer 2

A DataContext è economico da fare e non si guadagna molto memorizzandolo nella cache in questo modo.

Answer 3

Ho eseguito molte app Web da Linq a Sql e non sono sicuro se ciò che avresti funzionasse.

Il datacontext deve tenere traccia delle modifiche apportate ai propri oggetti e non lo farà in questa istanza.

Così quando vai a premere invia modifiche, non saprà che nessuno dei tuoi oggetti è stato aggiornato, quindi non aggiorna il database.

È necessario eseguire alcuni lavori aggiuntivi con il datacontext in un ambiente disconnesso come un'applicazione web. È più difficile con un aggiornamento, ma non così male. Non farei il cache e lo ricrearò semplicemente.

Answer 4

Anche il contesto non è transazionale quindi è teoricamente possibile che un aggiornamento possa verificarsi su un'altra richiesta e l'aggiornamento potrebbe non riuscire.

Answer 5

Preferisco creare una classe base di pagina (ereditata da System.Web.UI.Page) ed esporre una proprietà DataContext. Garantisce l'esistenza di un'istanza di DataContext per richiesta di pagina.

Questo ha funzionato bene per me, è un buon equilibrio IMHO. Puoi semplicemente chiamare DataContext.SubmitChanges() alla fine della pagina e ti assicuriamo che tutto è aggiornato. Assicurati inoltre che tutte le modifiche siano per un utente alla volta.

Fare questo tramite statico causerà dolore - temo che DataContext perderà traccia delle modifiche poiché sta tentando di tenere traccia delle modifiche per molti utenti contemporaneamente. Non penso che sia stato progettato per questo.