Diskuze: ASP.NET Core 2.0 - Jak použít DbContext mimo Controller
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Ahoj, děkuji za reakci 
Asi budeš mít v tomto pravdu a nejspíše proto jde ten DbContext použít jen v controlleru.
Já chci ale mít na webu panel, dejme tomu TOP 5 Nejnovějších článků, nebo na ten způsob něco takového. Prakticky Částečné zobrazení, díval jsem se na net a nikde jsem právě nenašel návod, kde použít PartialVie tak, abych mohl použít databázi a tam kde srovnávali PartialView s View Componentem bylo psáno, že ViewComponent má prakticky takový MiniController.
Zkrátka, jak udělat částečné zobrazení, kde částečné zobrazení bude tahat data z SQL pomocí EF ?
Děkuji
David Hartinger:18.2.2018 15:50
Podstata MVC architektury je snad pracovat s databází v modelech, ne v
kontrolerech Co jsem dělal v
ASP.NET, tak se v modelech normálně vytvořila nová instance DbContext v
bloku using a pomocí ní se potom s databází pracovalo. Něco
podobného jde určitě udělat i teď.
Ahoj,
sjel jsem právě dost tutoriálů a článků a většina tahala data z
databáze v Controlleru (do IEnumebrable kolekce například) a danou kolekci
předala přes return View() do Viewu. Ale je pravda, že pokud jsem četl
teorii, všude bylo psáno, že lézt do DB by se mělo v Modelu, ale v
praktických příkladech jsem všude viděl, že data tahají z Controlleru
Každopádně, lézt do DB
raději v modelu, nebo viewmodelu ?
Zkusím to skrze ten using blok a dám echo
Zatím díky
Ano, v tutoriálech najdeš použití contextu rovnou v controlleru a bohužel to najdeš i ve scaffoldnutých aplikacích CLIčkem / Visual Studiem.
Je to velký bullshit, za který microsoft dostává vlnu kritiky..
ještě větší bullshit je, až zjistíš - že bys měl používat cosi, čemu se říká UOW a pak zajdeš na stránky Microsoftu a zjistíš, že to tam implementují jako service locator a něco co porušuje miliardu principů včetně open-closed principle.
Takže poučení pro tebe je:
- DBContext v controllerech až u něčeho opravdu jednoduchého, třeba u vygenerované CRUD appky na základě DB scxhématu
- DBContext rozhodně nemá být POUZE v contorllerech
- Nedělej obrovské architektonické řešení, dokud ho nepotřebuješ, každé rozhnodnutí a vrstva navíc, by měla mít svoje opodstatnění
- V momentě kdy usoudíš. že potřebuješ něco jako UOW, jsou vesměs 2
správné implementace..
- UOW, které posíláš do repository v parametru a abstrahuje DBContext EF -
protože už samotný DBContext je ve skutečnosti UOW. Tedy něco jako:
using (uow = uow.Create()) {
repor.x(..., uow);
repor2.y(..., uow);
- UOW, které posíláš do repository v parametru a abstrahuje DBContext EF -
protože už samotný DBContext je ve skutečnosti UOW. Tedy něco jako:
}
s tím, že je ještě dobré, aby ta metoda ve které to máš, měla nullable
parametr UOW tak, aby si ho mohl "dědit":
methodA(Uow? parentuow) {
bool own = false;
Uow ownUOW = null;
// pokud je prebrane UOW, tak prebrat, jinak si vytvorit vlastni
if (parentuow==null) {
ownUow = new UOW();
ownUOW = true;
} else {
ownUow = parentuow;
}
repor.x(..., uow);
repor2.y(..., uow);
// commit / dispose pokud je vlastni (a neni parent)
if (own ) {
ownUow .Commit();
ownUow .Dispose();
}
}
je to z toho duvodu, aby si mohl dedit ten logicky celek a pak delat:
using (uow = new UOW()) {
anotherService.methodA(uow);
anotherService2.methodXYZ(uow);
}
a jelo ti to pod stejnou transakcito je ale pomerne voser, takze se to resi třeba přes nějaké aspekty a
method interception, případně pomocí metody 2
2) Najdeš si nějaké úložiště, kam si šoupeš ty UOW do stacku, při
usingu se to do stacku vkládá, na konci usingu (dochází k automatickému
dispose) se z toho stacku vybírá a dělá se commit (samozřejmě je tam
ještě nějaká logika nad tím, kde se kontroluje jestli nemá sdílet parent
UOW atd.)
Není to úplně jednoduché vymyslet dobře (obzvláště ve webovém
prostředí vzhledem k synchronization contextu) ani pro zkušeného
programátora a architekta,-- obzvláště, pokud má být jednoduché třeba
pak vyměnit Entity Framework a SQL za NoSQL a Mongo..
Proto bych ti doporučil si do začátků klidně vytvářet EF v controlleru.. Ono stejně 99% transakcí odpovídá 1 requestu. Takže vytváření v controlleru (nebo třeba nějaký IOC container s PerRequest resolverem, není uplně pekelná volba - ale ani ne nejlepší)
+20 Zkušeností
+2,50 Kč
@David:
Zkoušel jsem to pomocí bloku using, nicméně narazil jsem an stejný problém
- kompilátor křičí, že mi chybí parametr, kterým je DbContextOptions, a
právě nemám ponětí, jak tento parametr vytvořit 
O těch servisech slyším prvně, asi to budu muset dostutovat. Nějaká klíčová slova, pod čím to najít, nebo jak se tato problematika nazývá ?
@Marian
Nooo, abych pravdu řekl, mám teď v tom trochu guláš, respektive, hodně
pojmů. které jsi použil neznám, ale pogooglím, zkusím pochopit a pak mi to
bude dávat snad větší smysl
Jedu i hodně podle dokumentace od Microsoftu, tam také v Controlleru tahají data z DB.
Na ten EF jsem si docela zvykl, snažím se dělat i ve WPF, tam jej také používám a docela mi vyhovuje.
Zatím mi právě jde o to, jak udělat PartialView / ViewComponent tak, abych si mohl vytáhnout nějaká data z databáze. Momentálně nejideálnější by pro mě bylo, v modelu si vytvořit instanci dbcontextu, nicméně nemám ponětí jak tam narvat DBContextOptions, jak jsem psal výše.
Jak říkám, zkusím ještě prohledat web, tutoriály, nové pojmy a principy, které zde zazněly a snad budu o něco chytřejší.
Zatím děkuji všem
EDIT: Tak jsem to obešel tak, že jsem zrušil u ctoru DbContextu parametr DbContextOptions a vyřešil to skrze přepsání funkce onconfigure.
Zobrazeno 15 zpráv z 15.