problematika datového přístupu v business aplikacích
DESCRIPTION
Problematika datového přístupu v business aplikacích. Bc. Michal Jakubec MCSE, MCSD, MCDBA, MCTS http://www.jakubec.cz/. 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. Co nás nyní čeká ? (1/4). - PowerPoint PPT PresentationTRANSCRIPT
Problematikadatového přístupuv business aplikacích
Bc. Michal Jakubec
MCSE, MCSD, MCDBA, MCTS
http://www.jakubec.cz/
1
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
2
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
3
Na počátku stojí požadavky
Interakce
Uživatel Systém
4
Systém
Konceptuální model systému
Uživatelské rozhraní
Aplikační logika
Datové úložiště
Datový přístup
Uživatel
5
Kompetence vrstev modelu
Uživatelské rozhraní Aplikační logika Datový přístup• identifikace uživatele
• přihlášení• odhlášení
• přístup k funkcím systému
• nabídky• zkratkové klávesy
• vstup údajů• formuláře• ovládací prvky
• prezentace údajů• tabulky, grafy
• řízení přístupu• autentizace• autorizace
• vykonávání činností• zpracování údajů• koordinace aktivit
• kontrola přijatých údajů
• validace• verifikace
• sledování provozu• auditing
• práce s daty úložiště• načítání dat• aktualizace dat• výběr dat dle
podmínek• práce se strukturou
úložiště (volitelně)• načítání• aktualizace• porovnávání
• práce s konfigurací aplikace
6
Fyzické uspořádání vrstev
Datové úložiště
Uživatelské rozhraní
Aplikační logika
Datový přístup
Databázový server
„Tlustí“ klienti
Web
ový
serv
er
ProhlížečProhlížeč
Uživatelské rozhraní
Aplikační logika
Datové úložiště
Datový přístup
Prohlížeč
Databázový server
Klie
nti
Aplikační logika
Datový přístup
Datové úložiště
Uživatelské rozhraní
Databázový server
Apl
ikač
ní s
erve
r
„Chytří“ klienti
2-vrstváarchitektura
Webová architektura 3-vrstváarchitektura
7
Této oblasti se budeme dále věnovat!
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
8
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
9
Požadavky na datový přístup
Datový přístup
SQL Server
Oracle AccessBLOB
XMLXMLXML
Seznam položek Detail položky Tisková sestava
Off-lineúložiště
Uložit Storno
10
Metadata
Elementární práce se záznamy
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)
11
Detail položky
Uložit Storno
Hromadná práce se záznamy
Zobrazení záznamů v pohledech filtrace, řazení, stránkování, početnavigace mezi záznamy různých typůobecně dynamické dotazy => univerzální
Zobrazení záznamů v sestaváchspojování, seskupování, hierarchieobecně statické dotazy => jednoúčelové
12
Seznam položek
Statické dotazy Výběrové příkazy sestavené přímo v kódu
např. LINQ, NHibernate Criteria API Ideálně s podporou kontroly syntaxe
LINQ podporuje, NHibernate nikoliv Použití v kódu aplikační logiky a v sestavách
IList<Title> titles = session.CreateCriteria(typeof(Title)) .Add(Restrictions.Like("AuthorName", "Knuth%")) .Add(Restrictions.Eq("PublisherId", publisherId).List();
NHibernate
IList<Title> titles = from t in context.Titles where t.AuthorName.StartsWith("Knuth") and t.PublisherId == publisherId select t;
LINQ
13
Dynamické dotazy 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
<selector entity="Task" property="Id"> <condition property="Disabled" comparison="Equals" type="flag" value="false"/> <set junction="Or"> <condition property="Type.Mark" comparison="Equals" value="Development"/> <condition property="Type.Mark" comparison="Equals" value="Repair"/> </set> <condition property="State.Mark" comparison="Equals" value="Billed"/></selector>
14
SELECT T.IdFROM Task AS TINNER JOIN TaskType AS TT ON T.TypeId = TT.IdINNER JOIN TaskState AS TS ON T.StateId = TS.IdWHERE T.Disabled = 0 AND (TT.Mark = "Development" OR TT.Mark = "Repair") AND TS.Mark = "Billed"
Dynamický dotaz – ukázka
Název publikace ^2 Autor Vydavatelství ^1
Jádro systému Windows Dráb, Martin Computer Press
Umění programování Knuth, Donald E. Computer Press
Destilované UML Fowler, Martin Grada
Objektové programování Čada, Ondřej Grada
SELECT T.Name, T.AuthorName, P.NameFROM Title AS TINNER JOIN Publisher AS PON T.PublisherId = P.IdORDER BY P.Name, T.Name
15
Dynamický dotaz – restrikce
SELECT T.Name, T.AuthorName, P.NameFROM Title AS TINNER JOIN Publisher AS PON T.PublisherId = P.IdWHERE T.PublisherId = @DefaultPublisherIdORDER BY P.Name, T.Name
Název publikace ^2 Autor Vydavatelství ^1
Jádro systému Windows Dráb, Martin Computer Press
Umění programování Knuth, Donald E. Computer Press
Destilované UML Fowler, Martin Grada
Objektové programování Čada, Ondřej Grada
16
Dynamický dotaz – filtrace
SELECT T.Name, T.AuthorName, P.NameFROM Title AS TINNER JOIN Publisher AS PON T.PublisherId = P.IdWHERE T.PublisherId = @DefaultPublisherId AND T.AuthorName LIKE 'Knuth%'ORDER BY P.Name, T.Name
Název publikace ^2 Autor [Knuth*] Vydavatelství ^1
Jádro systému Windows Dráb, Martin Computer Press
Umění programování Knuth, Donald E. Computer Press
Destilované UML Fowler, Martin Grada
Objektové programování Čada, Ondřej Grada
17
Relační databázová úložiště
Prakticky „standardem“ ukládání dat v podnikových informačních systémechdostatek znalostí a zkušeností mezi vývojářidobrá 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
18
Úložiště objektů typu BLOB
Určeno pro správu velkých objemů datdokumenty, obrázky, audio, video
Možnosti realizacesamostatně v souborovém systému„in-line“, SQL Server FILESTREAM
Kombinovaná řešení mají vyšší náklady na provoz a údržbuzálohování i obnova by měla být atomická!
19
BLOB
Úložiště metadat 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.
20
Metadata
Off-line úložiště na klientu 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
21
Off-lineúložiště
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ě
22
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
23
Druhy datového přístupu
Přístup k relačním databázímADO.NET, NHibernate, Entity Framework, ...
Přístup k dokumentům XMLXmlDocument, XDocument, ...
Přístup k BLOB objektům (soubory)souborový systémSQL Server FILESTREAM
24
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 instancemiobjektově-orientované dotazy
25
Srovnání způsobů práce s DBKonvenční přístup
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();
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();
26
Pozor! Z důvodu přehlednosti kód neobsahuje ošetření korektního uvolnění prostředků (IDisposable).
Proč je ORM už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
27
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
28
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!
29
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
30
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
31
Konceptuální model (1/4)
Nalezení pojmů problémové domény
32
Publikace Autor ExemplářKategorie
Čtenář Výpůjčka Poplatek
Konceptuální model (2/4)
Vyznačení vztahů mezi pojmy
33
PublikaceAutor Exemplář
Kategorie
Čtenář VýpůjčkaPoplatek
PublikaceAutor Exemplář
Kategorie
Čtenář VýpůjčkaPoplatek
0..*1..*
1
0..*
0..*1
0..*1
1
0..*
10..*
Konceptuální model (3/4)
34
Určení násobnosti vztahů
Konceptuální model (4/4)
35
Přiřazení atributů
Značka : textNázev : textVydáno : datum
Publikace
Příjmení : textJméno : text
AutorZnačka : textPořízeno : datumCena : měna
Exemplář
Název : text
Kategorie
Značka : textPříjmení : textJméno : text
Čtenář
Půjčeno : datumVráceno : datum?
VýpůjčkaČástka : měnaRok : čísloZaplaceno : datum
Poplatek
0..*1..*
1
0..*
0..*1
0..*1
1
0..*
10..*
Doménový model aplikace (1/3)
Transformace identifikátorů
36
Mark : stringName : stringIssuedOn : DateTime
Publication
LastName : stringFirstName : string
AuthorMark : stringBoughtOn : DateTimePrice : decimal
Copy
Name : string
Category
Mark : stringLastName : stringFirstName : string
Reader
ProvidedOn : DateTimeReturnedOn : DateTime?
LoanPrice : decimalYear : intPaidOn : DateTime
Payment
0..*1..*
1
0..*
0..*1
0..*1
1
0..*
10..*
Doménový model aplikace (2/3)
Vyznačeny (primární) průchodnosti
37
Mark : stringName : stringIssuedOn : DateTime
Publication
LastName : stringFirstName : string
AuthorMark : stringBoughtOn : DateTimePrice : decimal
Copy
Name : string
Category
Mark : stringLastName : stringFirstName : string
Reader
ProvidedOn : DateTimeReturnedOn : DateTime?
LoanPrice : decimalYear : intPaidOn : DateTime
Payment
0..*1..*
1
0..*
0..*1
0..*1
1
0..*
10..*
Relační model aplikace (1/2)
Vytvořen dle doménového modelu
38
«pk» Id : intMark : nvarchar(8)Name : nvarchar(64)IssuedOn : datetime
Publication
«pk» Id : intLastName : nvarchar(32)FirstName : nvarchar(32)
Author
«pk» Id : intMark : nvarchar(8)Price : moneyBoughtOn : datetime
Copy
«pk» Id : intName : nvarchar(64)
Category
«pk» Id : intMark : nvarchar(8)LastName : nvarchar(32)FirstName: nvarchar(32)
Reader
«pk» Id : intProvidedOn : datetimeReturnedOn : datetime?
Loan«pk» Id : intAmount : moneyYear : intPaidOn : datetime
Payment
1
0..*
«fk» CategoryId
0..*1
«fk»PublicationId
«fk»ReaderId
0..*1
1
0..*
«fk» CopyId
«fk»ReaderId
10..*
Rank : int
Authorship
«pk»«fk»AuthorId
0..*1 11..*«pk»«fk»
PublicationId
Doménový model aplikace (3/3)
Rozšířen o prvky podporující ORM
39
Id : intMark : nvarchar(8)Name : nvarchar(64)IssuedOn : datetimeCategoryId : int
Publication
Id : intLastName : nvarchar(32)FirstName : nvarchar(32)
AuthorId : intMark : nvarchar(8)Price : moneyBoughtOn : datetimePublicationId : int
Copy
Id : intName : nvarchar(64)
Category
Id : intMark : nvarchar(8)LastName : nvarchar(32)FirstName: nvarchar(32)
ReaderId : intProvidedOn : datetimeReturnedOn : datetime?CopyId : intReaderId : int
Loan
Id : intAmount : moneyYear : intPaidOn : datetimeReaderId : int
Payment
10..*
0..*1
0..*1
10..*
10..*
Id : intPublicationId : intAuthorId : intRank : int
Authorship
0..*1 11..*
Relační model aplikace (2/2)
Rozšířen o prvky podporující ORM
40
«pk» Id : intMark : nvarchar(8)Name : nvarchar(64)IssuedOn : datetime
Publication
«pk» Id : intLastName : nvarchar(32)FirstName : nvarchar(32)
Author
«pk» Id : intMark : nvarchar(8)Price : moneyBoughtOn : datetime
Copy
«pk» Id : intName : nvarchar(64)
Category
«pk» Id : intMark : nvarchar(8)LastName : nvarchar(32)FirstName: nvarchar(32)
Reader
«pk» Id : intProvidedOn : datetimeReturnedOn : datetime?
Loan«pk» Id : intAmount : moneyYear : intPaidOn : datetime
Payment
1
0..*
«fk» CategoryId
0..*1
«fk»PublicationId
«fk»ReaderId
0..*1
1
0..*
«fk» CopyId
«fk»ReaderId
10..*
«uq» Id : intRank : int
Authorship
«pk»«fk»AuthorId
0..*1 11..*«pk»«fk»
PublicationId
Závislosti jednotlivých projektů
41
Access.DatabaseDomain
Client
Access
Logic
DEMO 1
Projektová struktura
42
Přístup přes Repository
Typově nespecifický přístup Zapouzdření CRUD a dotazů Implementuje IRepositoryProvider Třída Repository jako Singleton
43
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
44
DEMO 2
Repository, EntityBroker
45
Implementace dekorátorů
Zabezpečení přístupu Logování změn Neinvazivní mazání záznamů
46
DEMO 3
Implementace dekorátorů
47
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
48
DEMO 4
Ošetření vícevláknového přístupu
49
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
50
Závěr
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
Dotazy?
51