Is veelvuldige datakonteksklasse ooit gepas?

Question

Om LinqToSql ten volle in 'n ASP.net 3.5-toepassing te gebruik, is dit nodig om te skep Datakonteks klasse (wat gewoonlik gedoen word deur die ontwerper in VS 2008 te gebruik).Vanuit die UI-perspektief is die DataContext 'n ontwerp van die afdelings van jou databasis waaraan jy graag wil blootstel deur LinqToSql en is 'n integrale deel van die opstel van die ORM-kenmerke van LinqToSql.

My vraag is:Ek is besig om 'n projek op te stel wat 'n groot databasis gebruik waar alle tabelle op een of ander manier deur Foreign Keys met mekaar verbind is.My eerste neiging is om een ​​groot DataContext-klas te maak wat die hele databasis modelleer.Op dié manier kan ek in teorie (alhoewel ek nie weet of dit in die praktyk nodig sal wees nie) die Foreign Key-verbindings wat deur LinqToSql gegenereer word gebruik om maklik tussen verwante voorwerpe in my kode te gaan, verwante voorwerpe in te voeg, ens.

Maar, nadat ek daaroor nagedink het, dink ek nou dat dit meer sin kan maak om veelvuldige DataContext-klasse te skep, elkeen wat verband hou met 'n spesifieke naamruimte of logiese interverwante afdeling binne my databasis.My grootste bekommernis is dat om een ​​groot DataContext-klas heeltyd te instansieer en weg te gooi vir individuele bedrywighede wat verband hou met spesifieke areas van die databasis, 'n onnodige afdwinging op toepassingshulpbronne sou wees.Boonop is dit makliker om kleiner DataContext-lêers te skep en te bestuur as een groot een.Die ding wat ek sou verloor, is dat daar 'n paar veraf dele van die databasis sou wees wat nie deur LinqToSql navigeer kan word nie (alhoewel 'n ketting verhoudings hulle in die werklike databasis verbind).Daarbenewens sal daar 'n paar tabelklasse wees wat in meer as een DataContext sal bestaan.

Enige gedagtes of ervaring oor of veelvuldige DataKontekste (wat ooreenstem met DB-naamruimtes) gepas is in die plek van (of bykomend tot) een baie groot DataKontekstklas (wat ooreenstem met die hele DB)?

Answer 1

Ek stem nie saam met John se antwoord nie.Die DataContext (of Linq to Entities ObjectContext) is meer 'n "eenheid van werk" as 'n verbinding.Dit bestuur veranderingsopsporing, ens.Sien hierdie blogplasing vir 'n beskrywing:

Leeftyd van 'n LINQ na SQL DataContext

Die vier hoofpunte van hierdie blogpos is dat DataContext:

1. Is ideaal geskik vir 'n 'eenheid van werk' -benadering
2. Is ook ontwerp vir 'n 'staatlose' bedienerbediening
3. Is nie ontwerp vir langlewende gebruik nie

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

As ek dit in ag neem, dink ek nie dat die gebruik van meer as een DataContext enige skade sal aanrig nie - in werklikheid sal die skep van verskillende DataContexts vir verskillende soorte werk help om jou LinqToSql-implementasie meer bruikbaar en georganiseerd te maak.Die enigste nadeel is dat jy nie sqlmetal kan gebruik om jou dmbl outomaties te genereer nie.

Answer 2

Ek het oor dieselfde vraag gestry terwyl ek LINQ na SQL oor 'n erfenis-DB gepas het.Ons databasis is 'n bietjie van 'n pluimpie (150 tabelle) en na 'n bietjie nadenke en eksperimentering het ek gekies om veelvuldige DataContexts te gebruik.Of dit as 'n anti-patroon beskou word, moet nog gesien word, maar vir eers maak dit die lewe hanteerbaar.

Answer 3

Ek dink John is reg.

"My grootste bekommernis is dat om een ​​groot DataContext-klas heeltyd te instansieer en weg te gooi vir individuele bedrywighede wat verband hou met spesifieke areas van die databasis, 'n onnodige afdwinging op toepassingshulpbronne sou wees."

Hoe ondersteun jy daardie stelling?Wat is jou eksperiment wat wys dat 'n groot DataContext 'n prestasie-bottelnek is?Om veelvuldige datakontekste te hê is baie soos om veelvuldige databasisse te hê en maak sin in soortgelyke scenario's, dit wil sê, amper nooit.As jy met veelvuldige datakontekste werk, moet jy tred hou met watter voorwerpe aan watter datakonteks behoort en jy kan nie voorwerpe wat nie in dieselfde datakonteks is, in verband bring nie.Dit is 'n duur ontwerpreuk vir geen werklike voordeel nie.

@Evan "Die datacontext (of Linq to Entities ObjectContext) is meer 'n 'eenheid van werk' as 'n verbinding", en dit is juis waarom u nie meer as een datacontext moet hê nie.Hoekom sal jy meer as een "werkeenheid" op 'n slag wil hê?

Answer 4

Ek moet nie saamstem met die aanvaarde antwoord nie.In die vraag wat gestel is, het die stelsel 'n enkele groot databasis met sterk vreemde sleutelverhoudings tussen byna elke tabel (ook die geval waar ek werk).In hierdie scenario het die opbreek van dit in kleiner datakontekste (DC's) twee onmiddellike en groot nadele (albei genoem deur die vraag):

1. Jy verloor verhoudings tussen sommige tafels. Jy kan probeer om jou DC-grense verstandig te kies, maar jy sal uiteindelik in 'n situasie te staan ​​kom waar dit baie gerieflik sal wees om 'n verhouding van 'n tabel in een DC na 'n tabel in 'n ander te gebruik, en jy sal nie kan nie.
2. Sommige tabelle kan in verskeie DC's verskyn. Dit beteken dat as jy tabelspesifieke helpermetodes, besigheidslogika of ander kode in gedeeltelike klasse wil byvoeg, die tipes nie oor DC's versoenbaar sal wees nie.Jy kan dit omseil deur elke entiteitklas van sy eie spesifieke basisklas te erf, wat morsig raak.Skemaveranderinge sal ook oor verskeie DC's gedupliseer moet word.

Nou is dit beduidende nadele.Is daar voordele groot genoeg om dit te oorkom?Die vraag noem prestasie:

My grootste bekommernis is dat die instel en wegdoen van een groot datacontext -klas die hele tyd vir individuele bedrywighede wat verband hou met spesifieke gebiede van die databasis, 'n onnodige oplegging van toepassingsbronne sou wees.

Eintlik is dit nie waar dat 'n groot DC aansienlik meer tyd neem om te instansieer of in 'n tipiese werkeenheid te gebruik nie.In werklikheid, nadat die eerste instansie in 'n lopende proses geskep is, kan daaropvolgende kopieë van dieselfde DC feitlik onmiddellik geskep word.

Die enigste werklike voordeel van verskeie DC's vir 'n enkele, groot databasis met deeglike buitelandse sleutelverhoudings is dat jy jou kode 'n bietjie beter kan kompartementaliseer.Maar jy kan dit reeds met gedeeltelike klasse doen.

Die eenheid van werk-konsep is ook nie werklik relevant tot die oorspronklike vraag nie.Eenheid van werk verwys tipies na hoeveel 'n werk 'n enkele DC instansie doen, nie hoeveel werk 'n DC klas is bekwaam van doen.

Answer 5

In my ervaring met LINQ na SQL en LINQ na Entiteite is 'n DataContext sinoniem met 'n verbinding met die databasis.As jy dus veelvuldige datawinkels sou gebruik, sal jy verskeie Datakontekste moet gebruik.My ingewande reaksie is dat jy nie te veel van 'n verlangsaming sal opmerk met 'n DataContext wat 'n groot aantal tabelle insluit nie.As jy dit egter gedoen het, kan jy altyd die databasis logies verdeel op punte waar jy tabelle kan isoleer wat geen verband met ander stelle tabelle het nie en verskeie kontekste kan skep.