Diskuze: Vícevrstvá architektura
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 5 zpráv z 5.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
To je také úloha DALu, komunikaci s úložištěm. A z vnějšího pohledu je jedno, jeslti je to lokální DB, nebo třeba další server (přes API).
Nejvíce záleží na tom, jak moc jste naprasili právě tuto Datovou vrstvu, pokud jste používali ve WPF aplikaci nějaké ORM (třeb EF) a z té DAL vrstvy jste exposunli třeba IQueryable (že nějaká metoda DALu vracela iQueryable), tak se z toho teďka zblázníte a čeká vás překopávání větší části aplikaci, než by bylo za dobře napsaného kódu (a SOCu) nutné.
Dávám příklad s IQueryable, protože jeho vracení z metod, které jdou do "vyšší vrstvy" je naprosto nejčástější problém, kterého se dopouštějí i velezkušení vývojáři a bohužel je to i vidět v každém ukázkovém příkladu od microsoftu.
Děkuji za odpověď. Datová vrstva je realizována s pomocí EF a vzoru Repository, který však vždy (tedy doufám v to a pokud ne, chápu, že bude třeba to upravit) vrací o patro výš již materializovaná data. takže snad by to mělo jít relativně bezbolestně.
Prosím příště použijte na odpovědět,... zde je to totiž velmi důmyslně vymyšleno tak, že pokud nedáte odpovědět, tak je notifikován pouze autor topicu a NIKDO další už ne Kdybych napsal svůj názor na tento výmysl, tak opět dostanu jen 20x mínus, takže nic ...
Pokud máte v DALu v metodách v parametrech skutečně dotaz a vracíte již materializovaná data a nevracíte z metody IQueryable tak jste první bitvu vyhráli.
Druhá bitva vás čeká v podobě transakce. Zatímco v EF jste měli většinou transakci "realizovanou" pomocí EF data contextu, jeho lifecyklu a volání savechanges(), tak u té síťové už to tak jednoduché nebude. Pokud jste používali správně implementovaný Unit of work a né tak na ho*no jako to má microsoft na svým ASP stránkách (kde naperou Repository dovnitř UOW a naruší tak asi všechny programátorský principy), tak to budete mít ale o něco lehčí.
Budete tam muset buďto mít naimplementovanou podporu pro transakce na obou serverech, případně craftnout speciální request, který bude obsahovat všechny data, co se mají zpracovat v transakci, protože budete chtít mít bezstavové API (tj. bez transakce mezi requesty)
Zobrazeno 5 zpráv z 5.