Le classi multiple DataContext sono mai appropriate?

Question

Per utilizzare pienamente LinqToSql in un'applicazione ASP.net 3.5, è necessario creare Contesto dati classi (che di solito viene eseguito utilizzando la finestra di progettazione in VS 2008).Dal punto di vista dell'interfaccia utente, DataContext è una progettazione delle sezioni del database a cui desideri esporre tramite LinqToSql ed è parte integrante della configurazione delle funzionalità ORM di LinqToSql.

La mia domanda è:Sto impostando un progetto che utilizza un database di grandi dimensioni in cui tutte le tabelle sono interconnesse in qualche modo tramite chiavi esterne.La mia prima inclinazione è creare un'enorme classe DataContext che modelli l'intero database.In questo modo potrei in teoria (anche se non so se sarebbe necessario nella pratica) utilizzare le connessioni Foreign Key generate tramite LinqToSql per passare facilmente tra oggetti correlati nel mio codice, inserire oggetti correlati, ecc.

Tuttavia, dopo averci pensato un po', ora penso che potrebbe avere più senso creare più classi DataContext, ciascuna relativa a uno spazio dei nomi specifico o a una sezione logica interconnessa all'interno del mio database.La mia preoccupazione principale è che istanziare ed eliminare continuamente un'enorme classe DataContext per singole operazioni relative ad aree specifiche del database imporrebbe un'imposizione non necessaria sulle risorse dell'applicazione.Inoltre, è più semplice creare e gestire file DataContext più piccoli rispetto a uno grande.La cosa che perderei è che ci sarebbero alcune sezioni distanti del database che non sarebbero navigabili tramite LinqToSql (anche se una catena di relazioni le collega nel database vero e proprio).Inoltre, ci sarebbero alcune classi di tabelle che esisterebbero in più di un DataContext.

Qualche idea o esperienza sull'opportunità di più DataContext (corrispondenti agli spazi dei nomi DB) al posto di (o in aggiunta a) una classe DataContext molto grande (corrispondente all'intero DB)?

Answer 1

Non sono d'accordo con la risposta di John.Il DataContext (o Linq to Entities ObjectContext) è più una "unità di lavoro" che una connessione.Gestisce il rilevamento delle modifiche, ecc.Vedi questo post del blog per una descrizione:

Durata di un LINQ to SQL DataContext

I quattro punti principali di questo post del blog sono che DataContext:

1. È ideale per un approccio "unità di lavoro"
2. È inoltre progettato per il funzionamento del server "apolido"
3. Non è progettato per l'uso di lunga durata

4. Should be used very carefully after
   any SumbitChanges() operation.
   

Considerando ciò, non penso che l'utilizzo di più di un DataContext possa causare alcun danno, anzi, la creazione di diversi DataContext per diversi tipi di lavoro aiuterebbe a rendere l'implementazione di LinqToSql più utilizzabile e organizzata.L'unico svantaggio è che non saresti in grado di utilizzare sqlmetal per generare automaticamente il tuo dmbl.

Answer 2

Stavo discutendo sulla stessa domanda mentre adattavo LINQ to SQL su un DB legacy.Il nostro database è un po' enorme (150 tabelle) e dopo qualche riflessione e sperimentazione ho deciso di utilizzare più DataContext.Resta da vedere se questo sia considerato un anti-modello, ma per ora rende la vita gestibile.

Answer 3

Penso che John abbia ragione.

"La mia preoccupazione principale è che istanziare ed eliminare continuamente un'enorme classe DataContext per singole operazioni relative ad aree specifiche del database imporrebbe un'imposizione non necessaria sulle risorse dell'applicazione"

Come sostieni questa affermazione?Qual è il tuo esperimento che mostra che un DataContext di grandi dimensioni rappresenta un collo di bottiglia delle prestazioni?Avere più contesti dati è molto simile ad avere più database e ha senso in scenari simili, ovvero quasi mai.Se lavori con più contesti dati devi tenere traccia di quali oggetti appartengono a quale contesto dati e non puoi mettere in relazione oggetti che non si trovano nello stesso contesto dati.Questo è un odore di design costoso senza alcun vantaggio reale.

@Evan "Il dataContext (o Linq a Entities ObjectContext) è più di una" unità di lavoro "che una connessione" che è proprio il motivo per cui non dovresti avere più di un datacontext.Perché vorresti più di una "unità di lavoro" alla volta?

Answer 4

Non sono d'accordo con la risposta accettata.Nella domanda posta, il sistema ha un unico grande database con forti relazioni di chiave esterna tra quasi tutte le tabelle (anche il caso in cui lavoro).In questo scenario, suddividerlo in DataContext (DC) più piccoli presenta due svantaggi immediati e importanti (entrambi menzionati nella domanda):

1. Perdi le relazioni tra alcune tabelle. Puoi provare a scegliere saggiamente i limiti del tuo controller di dominio, ma alla fine ti imbatterai in una situazione in cui sarebbe molto conveniente utilizzare una relazione da una tabella in un controller di dominio a una tabella in un altro e non sarai in grado di farlo.
2. Alcune tabelle potrebbero essere visualizzate in più controller di dominio. Ciò significa che se si desidera aggiungere metodi helper specifici della tabella, logica aziendale o altro codice in classi parziali, i tipi non saranno compatibili tra i controller di dominio.Puoi aggirare questo problema ereditando ciascuna classe di entità dalla sua classe base specifica, il che diventa complicato.Inoltre, le modifiche allo schema dovranno essere duplicate su più controller di dominio.

Ora, questi sono svantaggi significativi.Ci sono vantaggi abbastanza grandi da superarli?La domanda menziona le prestazioni:

La mia principale preoccupazione è che istanziare e smaltire sempre un'enorme classe DataContext per le singole operazioni che si riferiscono a aree specifiche del database imponiamo un'imposizione inutile sulle risorse dell'applicazione.

In realtà, non è vero che un controller di dominio di grandi dimensioni richieda molto più tempo per istanziare o utilizzare in una tipica unità di lavoro.Infatti, dopo la creazione della prima istanza in un processo in esecuzione, è possibile creare quasi istantaneamente copie successive dello stesso controller di dominio.

L'unico vero vantaggio derivante da più controller di dominio per un unico database di grandi dimensioni con relazioni approfondite di chiave esterna è che puoi compartimentalizzare un po' meglio il tuo codice.Ma puoi già farlo con le lezioni parziali.

Inoltre, il concetto di unità di lavoro non è realmente rilevante per la domanda originale.L'unità di lavoro si riferisce in genere alla quantità di lavoro di una singola DC esempio sta facendo, non quanto lavoro sta facendo una DC classe È capace di fare.

Answer 5

Nella mia esperienza con LINQ to SQL e LINQ to Entities un DataContext è sinonimo di una connessione al database.Pertanto, se dovessi utilizzare più archivi dati, dovresti utilizzare più DataContext.La mia reazione istintiva è che non noteresti un grande rallentamento con un DataContext che comprende un gran numero di tabelle.Se lo facessi, tuttavia, potresti sempre dividere logicamente il database nei punti in cui puoi isolare tabelle che non hanno alcuna relazione con altri set di tabelle e creare più contesti.