Jsou více DataContext třídy někdy vhodné?

hlasů
27

Aby bylo možné plně využít LinqToSql v aplikaci ASP.NET 3.5, je nutné vytvořit DataContext tříd (což se obvykle provádí pomocí návrháře ve VS 2008). Z pohledu UI je DataContext je návrh oddílů databáze, které byste chtěli vystavit přes LinqToSql a je nedílnou součástí při nastavování funkce ORM z LinqToSql.

Moje otázka zní: Jsem vytvoření projektu, který používá velké databáze, kde jsou všechny tabulky propojeny nějakým způsobem přes cizí klíče. Můj první sklon, aby vznikl jeden velký DataContext třídu, která modely celé databáze. Tak jsem mohl teoreticky (i když nevím, jestli to bude potřeba v praxi) používají cizí klíč připojení, které jsou generovány pomocí LinqToSql snadno jít mezi propojenými objekty v mém kódu, vložte související objekty, atd

Avšak poté, co mu nějaká myšlenka, teď jsem si myslel, že to může větší smysl vytvořit více DataContext tříd, každý z nich ve vztahu ke konkrétnímu oboru názvů nebo logické vzájemně propojené sekce v mé databáze. Mým hlavním problémem je, že konkretizace a likvidaci jeden velký DataContext třídu po celou dobu pro jednotlivé operace, které se týkají konkrétních oblastí databáze bude ukládat zbytečné uložení na aplikačních zdrojů. Kromě toho, že je snazší vytvořit a spravovat menší DataContext souborů než jeden velký. Jde o to, že bych ztratit je, že tam bude nějaké vzdálené části databáze, která by neměla být splavný přes LinqToSql (přestože řetězec vztahů je spojuje do vlastní databáze). Navíc, tam by některé třídy tabulka, která by existovat ve více než jedné DataContext.

Jakékoliv myšlenky nebo zkušenosti o tom, zda více DataContexts (odpovídající DB jmenných prostorů) jsou vhodné namísto (nebo kromě) jednoho velkého DataContext třídy (což odpovídá celému DB)?

Položena 05/08/2008 v 06:54
zdroj uživatelem
V jiných jazycích...                            


5 odpovědí

hlasů
25

Nesouhlasím s Johnova odpověď. DataContext (nebo LINQ to Entities ObjectContext) je více „jednotky práce“, než spojení. Spravuje sledování změn, atd Viz tento příspěvek na blogu pro popis:

Životnost LINQ to SQL DataContext

Čtyři hlavní body tohoto blogu je, že DataContext:

  1. Je ideální pro „transakce“ přístupu
  2. Je určen také pro „bez“ provozu serveru
  3. Není určen pro použití s ​​dlouhým poločasem
  4. Should be used very carefully after
    any SumbitChanges() operation.
    

Vzhledem k tomu, že jsem si nemyslím, že použití více než jednoho DataContext by dělat žádné harm- ve skutečnosti, vytváření různých DataContexts pro různé druhy práce by pomohlo, aby vaše LinqToSql impelmentation více usuable a organizovaný. Jediná nevýhoda je, nebudete moci používat sqlmetal se automaticky vygeneruje váš dmbl.

Odpovězeno 07/08/2008 v 22:02
zdroj uživatelem

hlasů
4

Jsem byl hádky nad stejnou otázkou, zatímco retro tvarovky LINQ to SQL přes starší DB. Naše databáze je trochu nehorázná lež (150 tabulek) a po nějakém přemýšlení a experimentování jsem se rozhodl se použít více DataContexts. Ať už je to považováno za anti-vzor se teprve uvidí, ale teď to dělá život zvládnutelné.

Odpovězeno 05/08/2008 v 23:51
zdroj uživatelem

hlasů
3

Musím souhlasit s přijatou odpovědí. Na položenou otázku, že systém má jednu velkou databázi se silnými zahraničními klíčových vztahů mezi téměř každý stůl (i v případě, kdy pracuji). V tomto scénáři, drtit to do menších DataContexts (DC) má dvě bezprostřední a zásadní nedostatky (jak zmínil se o otázce):

  1. Ztratíte vztahy mezi některými tabulkami. Můžete se pokusit vybrat své DC hranice moudře, ale budete nakonec dostat do situace, kdy by bylo velmi vhodné použít vztah z tabulky v jednom DC do tabulky v jiném, a nebudete moci.
  2. Některé tabulky mohou objevit ve více DC. To znamená, že pokud chcete přidat pomocných metod tabulka specifických pro obchodní logiky, nebo jiný kód v dílčích kategorií, druhy nebudou kompatibilní přes DC. Můžete tento problém vyřešit tím, že zdědí každou třídu entity ze svého specifického základní třídě, která se dostane chaotický. Také změny schématu budou muset být duplikovány napříč různými DC.

Právě ty jsou významné nedostatky. Existují výhody dostatečně velká k překonání těchto problémů? Otázka zmiňuje výkon:

Mým hlavním problémem je, že konkretizace a likvidaci jeden velký DataContext třídu po celou dobu pro jednotlivé operace, které se týkají konkrétních oblastí databáze bude ukládat zbytečné uložení na aplikačních zdrojů.

Ve skutečnosti to není pravda, že velká DC trvá podstatně déle a tím vytvořit instanci nebo použít v typické jednotky práce. Ve skutečnosti se po vytvoření první instance v probíhajícím procesu následné kopie téhož DC mohou být vytvořeny téměř okamžitě .

Jedinou skutečnou výhodu z více DC pro jeden velký databáze s důkladnými zahraničními klíčových vztahů je, že můžete rozčlenit svůj kód o něco lépe. Ale můžete už to s částečnými třídami.

Také jednotky práce koncepce není příliš relevantní k původní otázce. Jednotka práce typicky se odkazuje na kolik práce jeden DC instance dělá, a ne kolik práce DC třída je schopen dělat.

Odpovězeno 17/06/2014 v 21:53
zdroj uživatelem

hlasů
3

Myslím, že John je správná.

„Mým hlavním zájmem je, že konkretizace a likvidaci jedné obrovské DataContext třídě po celou dobu pro jednotlivé operace, které se týkají konkrétních oblastí databáze bude ukládat zbytečné uložení na aplikačních zdrojů“

Jak podporujete toto tvrzení? Jaký je váš experiment, který ukazuje, že velká DataContext je místo výkonu? Mít více datacontexts je hodně jako mít více databází a má smysl v podobných situacích, to znamená, že málokdy. Pokud pracujete s několika datacontexts musíte sledovat, které objekty patří k němuž DataContext a nemůže týkat objekty, které nejsou ve stejném kontextu dat. To je nákladné konstrukce vůně pro žádný skutečný prospěch.

@Evan „DataContext (nebo LINQ to Entities ObjectContext) je více‚jednotky práce‘, než spojení“ To je přesně důvod, proč byste neměli mít více než jednu DataContext. Proč byste chtěli více než jednu „jednotku práce“ najednou?

Odpovězeno 27/08/2008 v 02:11
zdroj uživatelem

hlasů
1

Podle mých zkušeností s LINQ to SQL a LINQ k bytostem DataContext je synonymem pro připojení k databázi. Takže pokud byste měli používat více datových úložišť budete muset použít více DataContexts. Můj gut reakce byste si nevšiml, aby velká část zpomalení s DataContext, který zahrnuje velké množství tabulek. Pokud jste však můžete vždy rozdělit databázi logicky v místech, kde můžete izolovat tabulky, které nemají žádnou souvislost s ostatními soubory tabulek a vytvořit více kontextů.

Odpovězeno 05/08/2008 v 10:57
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more