Problematika datového přístupu v business aplikacích

1. Problematikadatového přístupuv business aplikacích Bc. Michal Jakubec MCSE, MCSD, MCDBA, MCTS http://www.jakubec.cz/

2. Obsah Stručně o architektuře aplikací Požadavky na datový přístup Možnosti datového přístupu Ukázka řešení datového přístupu

3. Co nás nyní čeká? (1/4) Stručně o architektuře aplikací Požadavky na datový přístup Možnosti datového přístupu Ukázka řešení datového přístupu

4. Na počátku stojí požadavky Interakce Uživatel Systém

5. Konceptuální model systému Systém Datový přístup Datové úložiště Uživatelské rozhraní Aplikační logika Uživatel

6. Kompetence vrstev modelu

7. Fyzické uspořádání vrstev 2-vrstváarchitektura Webová architektura 3-vrstváarchitektura „Tlustí“ klienti „Chytří“ klienti Prohlížeč Prohlížeč Prohlížeč Klienti Uživatelské rozhraní Uživatelské rozhraní Uživatelské rozhraní Aplikační logika Aplikační server Aplikační logika Webový server Aplikační logika Datový přístup Datový přístup Této oblasti se budeme dále věnovat! Datový přístup Datové úložiště Datové úložiště Datové úložiště Databázový server Databázový server Databázový server

8. Shrnutí • Funkčnost aplikace lze rozčlenit do vrstev (layers) • uživatelské rozhraní • aplikační logika • datový přístup • Fyzické umístění vrstev (tiers) určuje architekturu • 2-vrstvá (2-tier) architektura • 3-vrstvá/n-vrstvá (n-tier) architektura (distribuovaná) • webová architektura • V dalších částech se budeme věnovat výhradně vrstvě datového přístupu

9. Co nás nyní čeká? (2/4) Stručně o architektuře aplikací Požadavky na datový přístup Možnosti datového přístupu Ukázka řešení datového přístupu

10. Požadavky na datový přístup Storno Uložit Datový přístup Metadata Off-line úložiště SQL Server XML XML XML Access Oracle BLOB

11. Elementární práce se záznamy Storno Uložit • Operace se strukturovanými daty (CRUD) • vytvoření, úprava, smazání, načítání, vyhledávání • obecně řešeno pomocí O/R mapování • Operace s nestrukturovanými daty (BLOB) • ukládání, načítání, vyhledávání, indexace • řešeno individuálně (např. FILESTREAM)

12. Hromadná práce se záznamy • Zobrazení záznamů v pohledech • filtrace, řazení, stránkování, počet • navigace mezi záznamy různých typů • obecně dynamické dotazy => univerzální • Zobrazení záznamů v sestavách • spojování, seskupování, hierarchie • obecně statické dotazy => jednoúčelové

13. Statické dotazy NHibernate IList<Title>titles= session.CreateCriteria(typeof(Title)).Add(Restrictions.Like("AuthorName", "Knuth%")).Add(Restrictions.Eq("PublisherId", publisherId).List(); LINQ IList<Title>titles= from t in context.Titles wheret.AuthorName.StartsWith("Knuth") and t.PublisherId == publisherIdselect t; • Výběrové příkazy sestavené přímo v kódu • např. LINQ, NHibernateCriteria API • Ideálně s podporou kontroly syntaxe • LINQ podporuje, NHibernate nikoliv • Použití v kódu aplikační logiky a v sestavách

14. Dynamické dotazy <selectorentity="Task" property="Id"> <conditionproperty="Disabled" comparison="Equals" type="flag" value="false"/> <set junction="Or"> <conditionproperty="Type.Mark" comparison="Equals" value="Development"/> <conditionproperty="Type.Mark" comparison="Equals" value="Repair"/> </set> <conditionproperty="State.Mark" comparison="Equals" value="Billed"/> </selector> SELECT T.Id FROM Task AS T INNER JOIN TaskType AS TT ON T.TypeId = TT.Id INNER JOIN TaskStateAS TS ON T.StateId= TS.Id WHERE T.Disabled = 0 AND (TT.Mark = "Development" OR TT.Mark = "Repair") AND TS.Mark = "Billed" • Výběrové příkazy sestavené či upravené za běhu • zpravidla vyžadována vhodně definovaná syntax • objektový model potřebný pro programovou manipulaci • Použití zejména v uživatelsky definovaných pohledech • kombinují pevnou definici dotazu a volitelné filtrační podmínky

15. Dynamický dotaz – ukázka SELECT T.Name, T.AuthorName, P.Name FROM Title AS T INNER JOIN Publisher AS P ON T.PublisherId = P.Id ORDER BY P.Name, T.Name

16. Dynamický dotaz – restrikce SELECT T.Name, T.AuthorName, P.Name FROM Title AS T INNER JOIN Publisher AS P ON T.PublisherId = P.Id WHERE T.PublisherId = @DefaultPublisherId ORDER BY P.Name, T.Name

17. Dynamický dotaz – filtrace SELECT T.Name, T.AuthorName, P.Name FROM Title AS T INNER JOIN Publisher AS P ON T.PublisherId = P.Id WHERE T.PublisherId = @DefaultPublisherId AND T.AuthorName LIKE 'Knuth%' ORDER BY P.Name, T.Name

18. Relační databázová úložiště • Prakticky „standardem“ ukládání dat v podnikových informačních systémech • dostatek znalostí a zkušeností mezi vývojáři • dobrá kompatibilita produktů různých výrobců • intuitivní i pro neškolené uživatele („tabulky“) • V dohledné době „není lepší volba“ • již bylo investováno do relačních technologií • čistě objektová úložiště se zatím neprosadila

19. Úložiště objektů typu BLOB BLOB • Určeno pro správu velkých objemů dat • dokumenty, obrázky, audio, video • Možnosti realizace • samostatně v souborovém systému • „in-line“, SQL Server FILESTREAM • Kombinovaná řešení mají vyšší náklady na provoz a údržbu • zálohování i obnova by měla být atomická!

20. Úložiště metadat Metadata • Obsahuje informace o struktuře údajů, se kterými aplikace pracuje • Umožňuje přizpůsobení aplikace za běhu • pohledy, dynamické dotazy, business pravidla • Podporuje flexibilní implementaci zabezpečení • řízení a sledování přístupu k entitám, atributům • Implementováno staticky či dynamicky • doménové třídy Entity, Attribute, atd.

21. Off-line úložiště na klientu Off-line úložiště • Poskytuje možnost práce uživatele i bez připojení k primárnímu datovému zdroji • např. pracovníci v terénu mimo dosah sítě • Řešeno nejčastěji instalací „odlehčeného“ databázového stroje • např. MS SQL Server Express či Compact • Lze řešit také jednoduššími prostředky • serializací kolekce doménových objektů • serializací instancí třídy DataSet • pomocí práce se sadou dokumentů XML

22. Shrnutí • Komplexní požadavky na datový přístup • Zobrazení záznamů v pohledech • Zobrazení záznamů v sestavách • Operace se strukturovanými daty (CRUD) • Operace s nestrukturovanými daty (BLOB) • Obsluhujeme různé typy datových úložišť • Relační databázová úložiště • Úložiště pro BLOBy • Úložiště pro metadata, Off-line úložiště

23. Co nás nyní čeká? (3/4) Stručně o architektuře aplikací Požadavky na datový přístup Možnosti datového přístupu Ukázka řešení datového přístupu

24. Druhy datového přístupu • Přístup k relačním databázím • ADO.NET, NHibernate, Entity Framework, ... • Přístup k dokumentům XML • XmlDocument, XDocument, ... • Přístup k BLOB objektům(soubory) • souborový systém • SQL Server FILESTREAM

25. Možnosti přístupu k databázi • Elementární řádkový přístup (Command) • INSERT, UPDATE, DELETE, příp. SELECT • Manipulace s množinami řádků • serverový kurzor (Command/DataReader) • odpojený režim (DataAdapter/DataSet) • Objektově-relační mapování (ORM) • manipulace s entitními instancemi • objektově-orientované dotazy

26. Srovnání způsobů práce s DB Konvenční přístup Přístup přes ORM var ctx = new LibraryContext(); var a = new Author(); a.LastName = "Čapek"; a.FirstName = "Karel"; a.BornOn =new DateTime( 1890, 1, 9); ctx.AuthorSet.AddObject(a); ctx.SaveChanges(); var con = new SqlConnection( connString); var cmd = new SqlCommand( InsertCommandText, con); cmd.Parameters.AddWithValue( "@LastName", "Čapek"); cmd.Parameters.AddWithValue( "@FirstName", "Karel"); cmd.Parameters.AddWithValue( "@BornOn", new DateTime(1890, 1, 9)); con.Open(); cmd.ExecuteNonQuery(); con.Close(); Pozor! Z důvodu přehlednosti kód neobsahuje ošetření korektního uvolnění prostředků (IDisposable).

27. Proč je ORMužitečné? • Dobře zapadá do obecného vývojového procesu • analýza požadavků => konceptuální model • návrh řešení => doménový model • realizace řešení => ORM => relační datový model • Zjednodušuje práci aplikace s databází • vývojář soustředí výhradně na business logiku • nemusí řešit problémy datového přístupu • Vytváří oddělovací vrstvu mezi aplikací a databází • menší citlivost kódu aplikace vůči změnám relačních databázových struktur

28. V čem ORM působí potíže? • Obtížná volba té „správné“ platformy • existuje mnoho technologií s různou škálou funkčnosti • Skrývá implementační detaily relační databáze • vývojáři nedokáží odhadnout důsledky kódu, který tvoří • Často ovlivňuje strukturu doménových tříd • dědění z určené bázové třídy ORM • přítomnost atributů reprezentujících PK, FK • Nutno spravovat údaje o mapování • buď v samostatných souborech či jako anotace v kódu • V mezních případech vznikají problémy s výkonem

29. Používat či nepoužívat ORM? • ORM rozhodněano, ale samo nepostačí • vhodné zejména pro rozsáhlejší aplikace • Je vhodné oddělit použité ORM od kódu aplikační logiky (viz následující téma) • usnadní případnou změnu použitého ORM • vhodný a flexibilní je vzor Repository • nejedná se však o triviální problematiku! • V žádném případě však ORM nezbavuje vývojáře nutnosti rozumět relačním databázím!

30. Co nás nyní čeká? (4/4) Stručně o architektuře aplikací Požadavky na datový přístup Možnosti řešení datového přístupu Ukázka řešení datového přístupu

31. Příklad zadání aplikace • Navrhněte databázi informačního systému Městské knihovny • Systém bude evidovat publikace, jejich autory, kategorie a exempláře • Systém bude sledovat čtenáře, jejich výpůjčky a zaplacení ročních členských poplatků • Evidované údaje jednotlivých agend jsou požadovány v obvyklém rozsahu • jejich volba je na uvážení řešitele 

32. Konceptuální model (1/4) Nalezení pojmů problémové domény

33. Konceptuální model (2/4) Vyznačení vztahů mezi pojmy

34. Konceptuální model (3/4) Určení násobnosti vztahů

35. Konceptuální model (4/4) Přiřazení atributů

36. Doménový model aplikace (1/3) Transformace identifikátorů

37. Doménový model aplikace (2/3) Vyznačeny (primární) průchodnosti

38. Relační model aplikace (1/2) Vytvořen dle doménového modelu

39. Doménový model aplikace (3/3) Rozšířen o prvky podporující ORM

40. Relační model aplikace (2/2) Rozšířen o prvky podporující ORM

41. Závislosti jednotlivých projektů

42. DEMO 1 Projektová struktura

43. Přístup přes Repository Typově nespecifický přístup Zapouzdření CRUD a dotazů Implementuje IRepositoryProvider Třída Repository jako Singleton

44. Přístup přes EntityBroker<T> Typově specifický přístup Zapouzdření entitně-specifických dotazů Rozhraní IEntityBroker<T> Skeletální implementace IEntityBroker<T> Konkrétní třídy XxxBroker přístupné jako Singleton

45. DEMO 2 Repository, EntityBroker

46. Implementace dekorátorů Zabezpečení přístupu Logování změn Neinvazivní mazání záznamů

47. DEMO 3 Implementace dekorátorů

48. Jak na vícevláknový přístup alokace SessionManageru dle přistupujícího vlákna každé vlákno tak má k dispozici vlastní SessionManager nutno řešit situaci, kdy se pracuje s transakcemi

49. DEMO 4 Ošetření vícevláknového přístupu

50. Shrnutí • Tvorba datového modelu • konceptuální, doménový a relační model • Vytvoření entitních tříd a mapování • preferována strategie Database First • relační datové struktury jsou jednoznačné • Implementace Repository a dekorátorů • zapouzdření datových služeb => modularita • zabezpečení, mazání, auditing • Ošetření vícevláknového přístupu • snadné použití např. v ASP.NET