Správičky 2 814 Blogy 948 Fórum 18 713

Prehľad diskusie

photo
LINQ to SQL DataContext strategia
mma
21. 9. 2017 22:50:24
photo
RE: LINQ to SQL DataContext strategia
harrison314
22. 9. 2017 9:37:39
photo
RE: LINQ to SQL DataContext strategia
mma
22. 9. 2017 10:00:13
photo
RE: LINQ to SQL DataContext strategia
harrison314
25. 9. 2017 15:41:11
photo
RE: LINQ to SQL DataContext strategia
mma
25. 9. 2017 22:34:54
photo
RE: LINQ to SQL DataContext strategia
macop
26. 9. 2017 12:11:37
photo
RE: LINQ to SQL DataContext strategia
harrison314
26. 9. 2017 13:01:44
photo
RE: LINQ to SQL DataContext strategia
liero
26. 9. 2017 13:32:28
photo
RE: LINQ to SQL DataContext strategia
mma
26. 9. 2017 15:29:05
photo
RE: LINQ to SQL DataContext strategia
liero
27. 9. 2017 17:40:55
photo
RE: LINQ to SQL DataContext strategia
mma
27. 9. 2017 22:46:38
photo
RE: LINQ to SQL DataContext strategia
liero
28. 9. 2017 9:00:58
photo
RE: LINQ to SQL DataContext strategia
liero
29. 9. 2017 12:02:12
photo
RE: LINQ to SQL DataContext strategia
mma
3. 2. 2018 21:53:42
photo
RE: LINQ to SQL DataContext strategia
Liero
6. 2. 2018 16:21:42
photo
RE: LINQ to SQL DataContext strategia
mma
6. 2. 2018 18:09:04
photo
RE: LINQ to SQL DataContext strategia
T
10. 2. 2018 12:05:16
photo
RE: LINQ to SQL DataContext strategia
Liero
10. 2. 2018 15:46:20
photo
RE: LINQ to SQL DataContext strategia
Liero
10. 2. 2018 16:03:26
photo
RE: LINQ to SQL DataContext strategia
T
14. 2. 2018 17:40:02
photo
RE: LINQ to SQL DataContext strategia
Liero
15. 2. 2018 15:20:14
photo
RE: LINQ to SQL DataContext strategia
T
17. 2. 2018 11:01:35

LINQ to SQL DataContext strategia

photo
mma
21. 9. 2017 22:50:24
Body: 35
Najaktívnejší č.: 211

LINQ to SQL DataContext strategia

Ahojte,

chcem sa poradit o strategii pouzitia DataContext-u pre LINQ SQL. V poslednej dobe som o tom vela cital na forach a blogoch, ako vytvarat DataContext vzdy na "unit of work". Robim programy do priemyslu, vzdy je to nejaka desktop aplikacia, kde sa najprv z tabulky typov v DB vyberie nejaky typ vyrobku, a potom ako bezi vyroba sa postupne plni tabulka s protokolmi (vysledkami) pre kazdy spracovany vyrobok, prip. data do nejakych podtabuliek. Okrem toho, tieto zapisy prebiehaju v druhom vlakne. Momentalne to mam riesene tak, ze mam jeden globalny DataContext, co ma dve nevyhody, ze jednak sa mozu tie vlakna pobit a program spadne, a druhu, ked program bezi dlhsie bez restartu, spotrebovava pamat, uz som videl jeden bezat 3 mesiace, obsadenych cez 3GB pamate, totalne spomaleny, az hlasil timeouty. Podla toho co som cital toto nie je spravny pristup.

Ako to najlepsie urobit? Napada ma mat jeden DataContext pre ten vybraty typ, z ktoreho nacitam typ, a potom pre kazdy protokol vytvarat novy DataContext, aj spolu s novym spojenim na DB. Pri ukladani protokolov ale potom nesmiem nastavit referenciu na typ, iba nastavit jeho ID, aby sa protokol nepripojil k DataContextu pre typ. Novy protokol sa vytvara zhruba raz za 5-30s. Vytvarat vzdy nove spojenie na DB je asi v poriadku, este  ked sa automaticky pouzije connection pool. Alebo ako to najlepsie vymysliet?

[Reakcia]

photo
harrison314
22. 9. 2017 9:37:39
Body: 1165
Najaktívnejší č.: 24

RE: LINQ to SQL DataContext strategia

Najlepsie je to robit tak ako si povedal -Unit of Work.

Na kazdu samostatnu operaciu s databzou si vytvoris novu isntanciu Db contextu, ktoru aj disposnes.

Akykolvek globalny alebo zdielany db context ti prinesie len problemy.

 

[Reakcia]

photo
mma
22. 9. 2017 10:00:13
Body: 35
Najaktívnejší č.: 211

RE: LINQ to SQL DataContext strategia

Dik. Akurat teda ten typ musim drzat globalne cely cas, lebo z neho a prip. podtabuliek citam kadejake parametre, to asi nema zmysel vzdy nacitavat znovu. A co spojenie? Tiez vzdy vytvarat nove? Ja som zvykol drzat otvorene spojenie, ktore som kontroloval, tym som aj vedel, ze program je pripraveny na novy vyrobok, aby sa nestalo ze zbehne proces a potom zistim, ze nie je spojenie na DB. Ale tak asi je mala pravdepodobnost, ze ked nacitam typ, ze by sa mi nasledne nepodarilo otvorit spojenie, ked to bezi na tom istom pocitaci. Navyse je connection pool, tak pokym to nebude moc dlho necinne, zrejme sa aj tak pouzije predosle otvorene.

[Reakcia]

photo
harrison314
25. 9. 2017 15:41:11
Body: 1165
Najaktívnejší č.: 24

RE: LINQ to SQL DataContext strategia

Nmusis si drzat nic cely cas, doraz si  entity (z EF) mimo kontext je podla mna velka chyba navrhu.

Ked to spravis poriadne (nedrzat si DB context ani entity globalne), tak dopyty do databazy budu rovnake.

A aplikacia ti nebude drzat v RAM niekolko GB.

 

[Reakcia]

photo
mma
25. 9. 2017 22:34:54
Body: 35
Najaktívnejší č.: 211

RE: LINQ to SQL DataContext strategia

No neviem. Funguje to tak, ze po zapnuti obsluha vyberie typ / zada zakazku, nacitaju sa parametre, tolerancie, skompiluje sa sekvencia testu a dalsie, pocas toho sa vyhlasuju chyby, ak nieco nie je. A ak to vsetko prebehne bez chyby, povazuje sa program za pripraveny. Nasledne potom uz automaticky pride novy vyrobok, nejaky cas sa spracovava, pocas testu sa pouzivaju vsetky tie parametre. A ako by som to teda mal urobit, ked nie drzat tie objekty v pamati? Mal by som akoze za "unit of work" povazovat jeden test, pred kazdym vyrobkom to vsetko znovu nacitat a kompilovat? Toto sa mi zda byt spravne, obsluha vyberie parametre, povie s tymto nastavenim chcem teraz niekolko hodin bezat. Navyse ked to uz raz prebehne, predpoklada sa, ze parametre su ok, ze sa nebudu menit a nepredpoklada sa, ze by to uz mohlo hlasit nejake chyby okolo toho. Niekolko GB nebude drzat, to je ten problem, ze som mal cely cas jeden globalny kontext, ked pre ulozenie dalsieho protokolu vytvorim vzdy novy, budem drzat v pamati len tie parametre.

[Reakcia]

photo
macop
26. 9. 2017 12:11:37
Body: 685
Najaktívnejší č.: 32

RE: LINQ to SQL DataContext strategia

Co presne znamena "skompiluje sa sekvencia testu"?

[Reakcia]

photo
harrison314
26. 9. 2017 13:01:44
Body: 1165
Najaktívnejší č.: 24

RE: LINQ to SQL DataContext strategia

Ja som vravel o Globalnom Db contexte

[Reakcia]

photo
liero
26. 9. 2017 13:32:28
Body: 9610
Najaktívnejší č.: 6

RE: LINQ to SQL DataContext strategia

Odporucane strategie sa mozu lisit ak riesis backend a ak riesis nejaku dektopovu aplikaciu, ktora priamo pristupuje k DB.

Co je tvoj pripad?

 

 

[Reakcia]

photo
mma
26. 9. 2017 15:29:05
Body: 35
Najaktívnejší č.: 211

RE: LINQ to SQL DataContext strategia

Skompilovat sekvenciu testu, tak mame tam nieco ako davkovy subor, pri vybere typu sa to parsuje a vytvara sa list objektov prikazov s parametrami.

Globalny DB kontext - tak ano, nemusel by som drzat ten kontext, stacili by mi mozno samotne objekty, ale zase ked sa nejake parametre v programe zmenia, potrebujem ten objekt ulozit, a bez povodneho kontextu to neurobim.

Moj pripad je desktop aplikacia a priamo pristupe k DB.

[Reakcia]

photo
liero
27. 9. 2017 17:40:55
Body: 9610
Najaktívnejší č.: 6

RE: LINQ to SQL DataContext strategia

Globalny DataContext je v tvojom pripade najhorsi mozny antipattern, aky si mohol urobit. Nielen kvoli memory leaku, ale aj kvoli multithreadingu.

  1. Co sa tyka memory leaku, musis si uvedomit jednu vec. DataContext si uklada vsetky entity, ktore selectnes, pripadne ich do DataContextu pridas. Napr.

    var productRows = dataContext.ProductRows.Where(...).ToArray();

    kopie selectnutych ProductRows su odteraz ulozene v datacontexte, aby ked zavolas niekedy v buducnosti SubmitChanges() datacontext vedel zistit, co sa zmenilo.

  2. Ak mas multithreading, kde kazdy thread bude pristupovat ku globalnemu datacontextu, tak sa ti stane, ze sa ti budu mixovat UnitOfWorky. Inak povedane zmeny z jedneho threadu ti moze submitnut iny thread v nevhodnom case.

Teraz skusim vyvratit nejaky myty:

  1. "Drzim si connection na databazu". No nedrzis :) Okrem toho toto vobec neries. Nema to s DataContextom nic spolocne.  ConnectionTimeout ti moze vyprsat tak ci tak, ak nic dlhsie nic nerobis a vtedy si LinqToSql vyrobi novy connection bez ohladu na to, ci si drzis, alebo nedrzis DataContext.

    Ak sa chces poistit, pouzi retry pattern. Niektore ORM to robia dokonca za teba.
  2. "Nemozem pouzit object (entitu) v inom DataContexte". Ale mozes. Musis ju tam akurat manualne pridat a povedat, ci ju ma novy DataContext chapat ako novu entitu (SubmitChanges vygeneruje INSERT), alebo zmenenu (UPDATE), alebo ako nezmenenu. Ale toto vobec netreba robit.


Vo vseobecnosti plati pravidlo, ze DataContext by si mal drzat co najkratsie. 

tu je priklad toho, ako mozes drzat nejake data globalne, ale Datacontext drzat co najkratsie. Mas nejake globalne settingy nacitane z databazy, ktore potrebujes obcas updatnut:

public class Settings
{
   public int Id {get; set;}
   public string Setting1 {get; set;}
   public string Setting2 {get; set;}
}

public static class MyGlobalContext
{
   public static  Settings SettingsInstance {get; private set; }
  
    public static void UpdateSettings(string setting1, string settting2)
    {
        using(var db = new MyDataContext())
        {
             var setting = db.Settings.FirstOrDefault(s => s.Id == SettingsInstance.Id);
             setting.Setting1 = setting1;
             setting.Setting2 = setting2;
             db.SubmitChanges();
             SettingsInstance = setting;
        }
    }
}
 

DataContext ma zmysel drzat dlhsie iba vtedy, ked chces trackovat zmeny, ktore chces potom submitnut naraz. Napriklad nejaky datagrid, kde uzivatel moze pridavat/editovat/mazat riadky a vsetko potom ulozit jednym tlacitkom. Vtedy mozes pouzit DataContext na trackovanie zmien v tom datagride a vsetk to submitnut ako jeden unit of work. Ale jeden DataContext na jeden grid! 

Ale toto aj tak nieje tvoj pripad.

 

[Reakcia]

photo
mma
27. 9. 2017 22:46:38
Body: 35
Najaktívnejší č.: 211

RE: LINQ to SQL DataContext strategia

Ano, toho som si uz vedomy, ze globalny kontext nebolo najlepsie riesenie...

K bodom:
1. Ano, to viem. Vtedy som asi nad tym az tolko nerozmyslal alebo co, a az tak casto problem nevznikal. Na problem s jednym kontextom som narazil az ked vtedy program bezal 3 mesiace a ked som zacal rozmyslat nad tym, preco to parkrat spadlo kvoli multithreadingu.

2. Zrovna ten problem, co pises, mi nevznika, lebo v hlavnom threade sa iba obcas cosi nacita alebo zapise pri zmene parametrov, a druhy thread iba zapisuje, takze so submitmi nebol problem. Problem robi to, ze obcas sa stane, ze obidva sucasne chcu cosi nacitat a vtedy to spadne. Potom som zacal rozmyslat, ako to urobit lepsie, kadeco precital a zistil, ze to nerobim najlepsie.

K mytom:
1. No podla mna drzim :) Ja rucne vytvorim SqlConnection a to priradim DataContextu. To som robil preto, lebo pri vybere noveho typu zakladam novy kontext, a aby sa nemuselo otvarat nove spojenie. A tiez som mohol potom kontrolovat stav spojenia. Alebo aj v tomto pripade kontext po case zatvori spojenie, zapamata si connection string a zalozi nove ked treba? Okrem toho, ked mam vzdy aktivne spojenie, predpokladam ze zapis do DB prebehne okamzite, takze nemusim riesit zapisove operacie asynchronne (ten druhy thread je relativne casovo kriticky, komunikuje so zariadenim a je na druhej strane kontrolovany lifebitom).

2. Ano, to tiez viem. Ak tym myslis to, ze zavolat bud Attach alebo InsertOnSubmit, tak zrovna metodu Attach v tych viacerych blogoch, co som cital, moc neodporucali.

K tomu prikladu, ano, tak by sa to dalo. Pri tom sa mi zda ale zbytocne, ze preco mam znovu nacitavat objekt, ktory uz raz aj tak mam, a preco rucne prepisovat vsetky (alebo min vsetky zmenene) settingy. To by sa sice dalo vyriesit cez Attach, ale je to naozaj taky problem drzat si kontext k tomu objektu? Cele to riesenie ako si napisal mi pripada, ako by to bolo tak urobene jednoucelovo len preto, aby som nemusel drzat ten kontext. Ma aj iny vyznam to urobit takto? Mohol by som si drzat kontext k tomu aktivnemu objektu pre pripad zapisu zmien, a na ukladanie protokolov a vsetky ostatne operacie vzdy zalozit novy.

Zaver, tak taky pripad tiez mam, nad ktorym som rozmyslal ci to robim spravne, ale to sem nejdem teraz miesat.

[Reakcia]

photo
liero
28. 9. 2017 9:00:58
Body: 9610
Najaktívnejší č.: 6

RE: LINQ to SQL DataContext strategia

Ked rucne vyrobis SqlConnection, naco potom drzis DataContext? Protirecis si. Aj tak je to ale zbytocne.

Pozri sa, pri webovej aplikacii by si vytvaral datacontext pri kadom requeste, co moze byt kludne 100x za sekundu a ORM to zvlada v pohode.

Celkovo sa riadis prilis vela predpokladmi, ktore nemas overene. Najprv to nakod v sulade s tym, naco su jednotlive triedy urcene a co najjednoduchsie a potom ries optimalizacie.

Dohodnime sa, ze to nakodis tak, ze si budes datacontext vytvarat pri kazdej operacii. Ked budes mat problem s performance, prides sem znova.


Co sa tyka mojho prikladu, moze sa ti to zdat zbytocne. Ale predstav si, ze by ta entita mala ovela viac properties, no ty by si chcel v tejto metode updatovat iba tie 2 properties. Keby si si ju nenacital z databazy, tak by si pri submite prepisal vsetky property tym co mas v pamati. Predpoklad, ze to nevadi, sa ti moze lahko vypomstit. Alternativne by si mohol drzat datacontext len pre tuto jednu entitu....

[Reakcia]

photo
liero
29. 9. 2017 12:02:12
Body: 9610
Najaktívnejší č.: 6

RE: LINQ to SQL DataContext strategia

@mmt: dalo by sa to aj takto, len tu menis SettingInstance este skor ako mas istotu ze to je ulozene v DB:

public static class MyGlobalContext
{
   public static  Settings SettingsInstance {get; private set; }
   
    public static void UpdateSettings(string setting1, string settting2)
    {
        using(var db = new MyDataContext())
        {
             db.Settings.Attach(SettingInstance);
             SettingInstance.Setting1 = setting1;
             SettingInstance.Setting2 = setting2;
             db.SubmitChanges();
        }
    }
}

workaround by bol:

var settings = new Settings { Id = SettingInstance };
db.Settings.Attach(setting);
settings.Setting1 = setting1;
settings.Setting2 = setting2;
db.SubmitChanges();

SettingsInstance = settings;        




[Reakcia]

photo
mma
3. 2. 2018 21:53:42
Body: 35
Najaktívnejší č.: 211

RE: LINQ to SQL DataContext strategia

No, povodne som neplanoval uz na toto odpisovat, sa mi zdalo ze uz to nema vyznam, ale v poslednej dobe som kadeco skusal aj v inych pripadoch nez o com som povodne pisal, a asi este napisem. K poslednym bodom na mna sa uz nejdem vyjadrovat.

Skusal som nedrzat kontext k objektu, ktory drzim globalne na cas, kym je potrebny. Pokym ho nepotrebujem menit, je to ok, ked ho chcem niekde priradit k inemu objektu, nastavim len ID a nie referenciu na objekt a je to bez problemov. Ked ho potrebujem upravit, je to horsie. Tvoj priklad s Attach som nerozchodil... Ako som aj predtym pisal, metodu Attach vo viacerych blogoch neodporucali, pokym to nie je nutne. Pri roznych pokusoch to vzdy hadzalo rozne vynimky bud pri Attach alebo SubmitChanges. Mozno metode Attach nerozumiem do hlbky, ale nerozchodil som to. Mozem urobit to, co si mi tiez navrhoval, ze pred zmenou si nacitat objekt z DB, zapisat zmeny a ulozit, ale v tom pripade musim manualne porovnat vsetky property a zapisat zmeny (alebo bez porovnavania prepisat vsetko).

Je to fakt taky problem drzat si data kontext k tomu jednemu objektu? Situacia je taka, ze desktop aplikacia vzdy bezi ako single instance, takze nikto iny do DB nepristupuje, drzi si svoj objekt s parametrami, obcas pouzivatel otvori okno, nieco z toho zmeni a ulozi. Riesit attach (neviem ako) alebo znovu nacitavat objekt a porovnavat a prepisovat zmeny, aky to ma este iny vyznam okrem toho, aby som nemusel drzat data context k objektu? Ak objekt planujem upravovat, nie je "unit of work" cas, dokedy potrebujem tento objekt priebezne upravovat a ukladat?

A este sa spytam na iny pripad, ked si predtym spominal tie datagridy. Ako by si riesil nasledovnu situaciu, mam datagridview, kde mam povedzme zoznam faktur. Vyberem jednu, kliknem na edit, otvori sa mi dialog, kde viem zmenit vlastnosti faktury a editovat polozky faktury (podtabulka). V tomto dialogu dam bud OK, vsetky zmeny sa ulozia a v datagridview sa zobrazia upravene vlastnosti alebo dam Cancel a vsetky zmeny sa zahodia. Samozrejme potom si mozem zvolit inu fakturu a zase dat edit. Ide mi hlavne o to cancel pri pridavani / uprave / mazani poloziek z podtabulky.

[Reakcia]

photo
Liero
6. 2. 2018 16:21:42
Body: 9610
Najaktívnejší č.: 6

RE: LINQ to SQL DataContext strategia

 "musim manualne porovnat vsetky property a zapisat zmeny (alebo bez porovnavania prepisat vsetko"

myslim ze nemusis. DataContext je dostatocne mudry nato, aby zistil, ktore properties sa zmenili. Tak to zvycajne byva pri inych ORM, napr EntityFramwork, malo by to tak byt aj pri LinqToSql.

"Mozno metode Attach nerozumiem do hlbky, ale nerozchodil som to"

ked attachnes entitu do DataContextu, kde predtym nebola, dostanes sa do stavu, ako keby si ju prave nacital z databazy. V tomto momente DataContext zacina trackovat zmeny.
Ked zavolas SubmitChanges, nestane sa nic, bez ohladu na to, ci si tu entitu zmenil predtym ako si ju attachol.
Ked jej nastavis nejake properties a zavolas SubmitChanges, zmeny sa ulozia.

"Je to fakt taky problem drzat si data kontext k tomu jednemu objektu"

Drzat k jednemu objektu to az taky velky problem nieje, lebo vtedy to je len lokalny DataContext. Ale ty si hovoril o jednom globalnom DataContexte na vsetko.

"DataGrid"

V tomto pripade by som mal pre DataGrid jeden DataContext iba na nacitanie itemov a hned ho disposnem.
Ked kliknes na edit, posles do dialogu nie entitu, ale iba IDcko. Dialog si entitu nacita vo vlastnom DataContexte, ktory si mozes drzat az kym nezavolas Save alebo Cancel. Po zatvoreni dialogu ti uz len ostava refreshnut DataGrid.

Je to logicke: Jeden dialog = jeden Unit Of Work.

Teoreticky by si mohol aj reusovat DataContext a pri cancel nejako revertovat zmeny (https://stackoverflow.com/questions/259219/how-can-i-reject-all-changes-in-a-linq-to-sqls-datacontext), ale musel by si si dat pozor, ze pri otvarani dialogu nemas v DataContexte ziadne zmeny cakajuce na submit.

Pokial by si chcel mat save / cancel tlacitka niekde pri datagride, nie v dialogu, s tym ze by si vedel poeditovat viacero entitit a savnut vsetko naraz, tak budes mat iba jeden DataContext, ktory si budes drzat.


Cely problem drzania DataContextu je v tom, ze SaveChanges ulozi vsetky zmeny, bez ohladu na to kde si ich urobil. Pokial mas multithreading tak to je cesta do pekla.

Mimochodom, zabudni na LinqToSql a zacni pouzivat Entity Framework, idealne Entity Framework Core 2.

[Reakcia]

photo
mma
6. 2. 2018 18:09:04
Body: 35
Najaktívnejší č.: 211

RE: LINQ to SQL DataContext strategia

Attach

To mi je jasne, ze by to malo fungovat tak ako pises. Ale ked som to skusal, Attach vyhodi vynimku ze "An attempt has been made to Attach or Add an entity that is not new, perhaps having been loaded from another DataContext.  This is not supported". V helpe k Attach pisu toto: "Do not try to Attach an entity that has not been detached through serialization. Entities that have not been serialized still maintain associations with deferred loaders that can cause unexpected results if the entity becomes tracked by a second data context". Skusal som urobit aj kopiu objektu a na nu dat Attach, to mi preslo, ale pri SubmitChanges to hodi zase vynimku "Row not found or changed". Cital som na tuto temu zopar clankov a Attach dost neodporucali, pokym to nie je nutne.

"DataGrid"

Ok, tak by to islo. Akurat na ten refresh DGV si musim zapamatat, ktore riadky su vybrane, prip. aj prvy zobrazeny riadok, a po refreshi to obnovit. To ale neni problem, len ci to nebude viditelne blikat. To s tym revertovanim zmien sa mi nepaci.

Este ma napadla jedna vec. Co by si povedal na to, keby som drzal k tomu DGV datacontext, a po ulozeni zmien v dialogu zavolal v datacontexte pre DGV Refresh s modom KeepCurrentValues na ten jeden objekt? Nemusel by som refreshovat cely DGV, riesit ktore riadky boli vybrane, kde to bolo zobrazene, refreshol by sa len ten jeden objekt.

"Entity Framework"

Uz som uvazoval nad EF, ale este som sa nedostal k tomu, ze by som si to poskusal, co by to vsetko obnasalo.

 

Dik za odpoved, uz nevidim rozpor :) Este rozmyslam, co so spojenim do DB, teraz som ho vytvaral manualne. Nemal by som problem to urobit tak, ze spojenie manualne riesit nebudem a necham to na datacontexty, nech si robia podla potreby, ale... Vadi mi, ze pri spusteni operacie nebudem vediet, ci bude DB dostupna. A ta operacia je na niektorych zariadeniach nie len test, ktory sa da opakovat, ale moze to byt aj montazna operacia, takze po dokonceni zrazu zistim, ze neviem ulozit vysledky do DB. Jasne, aj ked budem drzat spojenie moze nastat chyba, ale takto aspon viem, ze mam spojenie. Druha vec je, ze ked sa mi na zaciatku podari nacitat parametre, tak zrejme je DB ok a nebude problem ani zapisat vysledky. Dalsia vec je este ta, ze pri chybe to moze trvat aj 15 sekund, kym to skonci, takze ten cas po dokonceni operacie sa to bude tvarit, ze sa nic nedeje. Lenze, mam tam aj multithreading... Co je komplikacia, to by som musel bud drzat dve spojenia, jedno pre proces a druhe pre okna, ale to je take pofiderne, kedy bude dovod pracovat s DB este s nejakeho ineho vlakna. Alebo drzat jedno spojenie pre proces a v ostatnych vlaknach nech si datacontexty riesia spojenie ako chcu. Alebo drzat jedno a mat mutex na DB, to ale nie je moc prakticke. Alebo nedrzat nic (to sa asi robi bezne ako pises), s tym ze je naozaj mala pravdepodobnost, ze bude problem so spojenim. Ako si hovoril, serverove aplikacie robia vela spojeni za sekundu a funguje to. Mozno by to bolo vobec najlepsie, akurat teraz mam na statusbare take pekne policko DB, ktore je bud zelene alebo cervene, a tazko sa s nim lucit :D

[Reakcia]

photo
T
10. 2. 2018 12:05:16
Body: 21430
Najaktívnejší č.: 2

RE: LINQ to SQL DataContext strategia

@mma:

attach - to je preto, ze Ti zostala attachnuta entita v inom kontexte. Bud ju musis odregistrovat z jedneho a nasledne zavesit na druhy alebo bude robit to, ze nikdy nebudes pouzivat priamo entity v prezentacnej vrstve. Na to existuje niekolko technik ale prinasa to uz nejaku dodatocnu pracnost, ktora sa ale zvacsa vyplati. 

grid - to co Ti navrhuje Liero je taka technika, ked mas tenkeho weboveho klienta a pri tucnom je to zvacsa antipattern.(edit-save, edit-save) Ty mas tucneho a mozno chces umoznit napr. vykonanie naraz niekolkych zmien v gride ....a pripadne inline edit. Neviem, aky grid pouzivas a ake ma moznosti.

Ale v zasade je postup taky, ze nacitas itemy do gridu, grid si trackuje zmeny sam, na konci("ked user stlaci Save") si vypitas od neho co sa zmenilo (co je nove, co bolo aktualizovane), otvoris si context aka UoW a a premietnes do neho tieto zmeny a das save.

(su aj dalsie moznosti a sposoby implementacie v zavilosti od toho aky control a UI pattern pouzivas...ale ludia zacali retardovat moznosti tucneho klienta, co sa prejavuje napr. aj v tom, ze vela cast frameworkov pre rich js klientov vzisla z takejto mentality a teraz ich ohybaju aby dokazali priniest to, co tucny klient naozaj ponukat moze a ma, takze bacha na to :-)

Zacat s EF6 je v tvojom pripade vyhodnejsie ako s EF7 (ked dam bokom, ze mas asi windows alebo WPF aplikaciu), pretoze ma stale designer (ak pracujes sposobom najpr. databazovy model, potom drag and drop do Linq2SQL designeru.) Krivka prechodu z Linq2SQL by nemala byt nijako dlha.

Navyse V EF Core 2 chybaju stale elementarne "enterprise" veci (okrem designera), novy release je v nedohladne aj ked su mnohe aspon naplanove, takze neodporucam nechat zvadzat unahlenymi komunitnymi radami. (sam fungujem s EF Core 2)....

@liero:

"DataGrid jeden DataContext iba na nacitanie itemov"

Toto je cisty query scenar, najdolezitejsia vec je vypnut object tracking a prinutit ORM aby urobil priamy SQL dotaz, tracking je v tomto pripade uplne zbytocny resp. kontraproduktivny. (aj cely UoW)

"Je to logicke: Jeden dialog = jeden Unit Of Work."

Unit of work => Jedna atomicka operacia typicky nad jednym aggregatom -> jedno tranzakcne boundary..."obrazovka" je odveci kriterium....to kedysi boli take skvele napady instancovat kontext na webe spolu so screenom, nastastie som tu uz dlho nevidel propagovat.

UoW ma (logicky) zmysel jedine pri "command", nie "query". Problemom je, ze DataContext je ovela viac(patternov v jednom), nez len UoW.

Paradoxne, kludne pri queries by mohol shareovat jednu instanciu contextu a specialne v jeho pripade.(aj ked usetrim len minimum) a len na updates vytvarat "UoW"/dedikovny kontext.

 

 

 

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
10. 2. 2018 15:46:20
Body: 9610
Najaktívnejší č.: 6

RE: LINQ to SQL DataContext strategia

"DataGrid jeden DataContext iba na nacitanie itemov"

Toto je cisty query scenar, najdolezitejsia vec je vypnut object tracking a prinutit ORM aby urobil priamy SQL dotaz, tracking je v tomto pripade uplne zbytocny resp. kontraproduktivny. (aj cely UoW)

samozrejme

"obrazovka" je odveci kriterium - samozrejme, ale v tom scenari co opisoval to sedelo. Hned nato som spominal aj alternativny scenar, myslim ze tvrdime to iste.

 

btw, nema LinqToSQL, pripadne EF nahodou taku feature, ze ked mas v datacontexte attachnutu entitu, tak si vies refreshnne jej aktualny stav z DB?

using(var dataContext1 = new DataContext())
{
    var entities =  dataContentext1.MyTable.ToList();
    var entity1 = entities[0];
    
   using(var dataContext2 = new DataContext())
   {
        //load entity1 in another datacontext
        var entityToEdit = dataContext2.MyTable.First(e => e.Id == entity1.Id);
        entityToEdit.SomeField = "Edited";
        dataContext2.SubmitChanges();
   }
   
    //entity1 is attached. 
    //will it be detached or refreshed with updated values?
    dataContext1.MyTable.ToList(); 

}



[Reakcia]

photo
Liero
10. 2. 2018 16:03:26
Body: 9610
Najaktívnejší č.: 6

RE: LINQ to SQL DataContext strategia

k tomu master/detail scenaru este jeden sposob:

V Edit obrazovke sa bindujes na ViewModel a az pri Save updatujes entitu. Tym padom nemusis riesit Cancel. To ci si pri save vytiahnes entitu nanovo, alebo si ju posunies z datagridu je uz na tebe.

Ako povedal @T, da sa to riesit na vela sposobov, zalezi hlavne od poziadaviek na UX, komplexnosti celeho systemu atd. 

Ten moj prvy je najjednoduchsi a najmenej nachylny na chyby, ale z UX hladiska je to naozaj antipattern.

[Reakcia]

photo
T
14. 2. 2018 17:40:02
Body: 21430
Najaktívnejší č.: 2

RE: LINQ to SQL DataContext strategia

"nema LinqToSQL, pripadne EF nahodou taku feature"

Nechapem tu otazku @liero...kazdy kontexte to ma cachenute nezavisle od seba....mozes urobit .Entry().Reload() ale je to divny use case (dva kontexty)...jeden simuluje queryovanie a druhy update?

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
15. 2. 2018 15:20:14
Body: 9610
Najaktívnejší č.: 6

RE: LINQ to SQL DataContext strategia

je to ten use case, kde mas jeden context pre readonly datagrid a druhy pre edit view. 

Nebol by problem so scope datacontextu, ani s preblikavanim pri refreshi, ani s revertovanim zmien pri cancel.

[Reakcia]

photo
T
17. 2. 2018 11:01:35
Body: 21430
Najaktívnejší č.: 2

RE: LINQ to SQL DataContext strategia

@liero: to by si musel mat ale zapnuty tracking na query contexte,  aby Ti zafungoval refresh, co popiera cely jeho zmysel. Je to taky workaround keby si chcel nieco rychlo vyprodukovat, ale na vacsom projekte to nedava zmysel. Ako som pisal, vacsina normalnych gridov ma inline edit mode...takze co zeditujes vidis a riesis len ulozenie zmen, ktore Ti vie poskytnut, netreba robit refresh.

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]



Najaktívnejší užívatelia
1. 37775 b. photo vlko
2. 21430 b. photo T
3. 15955 b. photo spigi
4. 15450 b. photo Anonymous
5. 11120 b. photo dudok
6. 9610 b. photo Liero
7. 6910 b. photo siro
8. 6245 b. photo slavof
9. 5395 b. photo duracellko
10. 4640 b. photo xxxmatko