VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA

1. VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA Zbyněk Šlajchrt http://java.vse.cz/4it447/HomePage Část 6.

2. Perzistentní vrstva Prezentační vrstva "Jak aplikace vypadá" Servlety JSP Filtry Business vrstva "Co aplikace dělá" Bezstavové EJB Beans Stavové EJB Beany Message Driven Beany Perzistentní vrstva "Co aplikace je" JPA Entity JMS Fronty JMS Topiky

3. Entita • Perzistentní doménový objekt (PDO) • Objekt • Atributy, metody, dědičnost ... • Doménový • Doménou rozumíme oblast, pro kterou je aplikace navržena • Doménový objekt modeluje jsoucno z domény aplikace • Faktura, objednávka, zboží, zákazník - z domény e-business • Kniha, výpůjčka, čtenář, upomínka - z domény knihovnictví • Perzistentní • Modelované jsoucno má trvalý charakter • Data jsou uložena v úložišti, které je schopné uchovávat data 'libovolně' dlouho

4. Entita v EJB3 (JPA) • POJO (Plain Old Java Object) • Lze vytvářet pomocí new operátoru • Testovatelné • Atributy třídy entity představují • sloupce v databázi • vazby na jiné entity • Operace (business logika) nad entitou by měly být vyjádřeny jako metody třídy entity • Anti-vzor Anemic Entity (Fowler) - nedochůdče • Nikoliv za každou cenu – pokud operace obnáší interakce mezi více entitami, lépe řešit např. session EJB

5. Entita - příklad

6. Kontext perzistence • Promítání a načítání stavu entity z databáze je možné pouze pokud se entita nachází v kontextu perzistence (Persistence Context) – připojená entita (attached) • Mimo tento kontext je entita prostým objektem bez vazby na úložiště – odpojená entita (detached) • V kontextu jsou sledovány změny stavu entity • stav je synchronizován se stavem v db • synchronizace může být vyvolána explicitně či implicitně • má na starosti objekt EntityManager • při uzavírání kontextu se všechny entity odpojí

7. Transakční kontext perzistence • Doba života tohoto kontextu je pouze po dobu trvání transakce • často v rámci volání jedné metody klientem • V okamžiku ukončení transakce se uzavře i kontext • všechny entity v kontextu se odpojí • pouze pokud transakce proběhne v pořádku (commit), změny v entitách se synchronizují z databází • Poznámka: platí pouze pro kontext řízený aplikačním serverem • je možné vytvářet si vlastní kontext perzistence

8. Rozšířený kontext perzistence • Doba života tohoto kontextu není svázána s trváním transakce • Všechny entity v kontextu zůstávají připojeny i když je transakce ukončena • Velmi užitečné v případech, kdy chceme provádět delší konverzace s databází a zároveň se vyhnout dlouhým transakcím • dlouhé transakce blokují "vzácné" prostředky systému • JDBC připojení, zámky

9. Rozšířený kontext - pseudokód

10. Entita coby přenosový objekt (TO) • Odpojenou entitu lze použít jako přenosový objekt • lze ji serializovat a poslat na klienta • klient může provést úpravy a odeslat ji zpět na server • na serveru se musí provést tzv. merge • sloučení s verzí entity v kontextu (pokud v něm není, načte se) • vzor Transfer (Value) Object • V případě složitějších entit může být problematické • přenášení celého grafu závislých entit může brzdit síť • řešení: závislosti lze dohrávat dynamicky (lazy) • nevýhoda – v různých situacích je na klientovi entita s různě připojenými závislými entitami (NullPointerException)

11. Životní cyklus entity Neexistuje instanciace garbage collector Existuje v paměti odstranění z databáze - volání persist na EM - výsledek dotazu - vyčištění na kontextu - serializace odstranění Odpojená Připojená Odstraněná merge • - obnova stavu (refresh) • aktualizace stavu settery

12. Callback metody na entitách • Během životního cyklu entity dochází ke generování událostí • Tyto události lze odchytávat přímo v entitě prostřednictvím tzv. callback metod • Události • vkládání (persisting) • aktualizace (updating) • mazání (deleting) • výběr (selecting) • Všechny události mají Pre a Post callback metody • výjimkou je výběr, který má pouze Post callback

13. Životní cyklus a callback metody Neexistuje find() nebo JPQL garbage collector Existuje v paměti @PostLoad @PostRemove @PrePersist @PostPersist @PreRemove Odpojená Připojená Odstraněná @PostLoad, když se nahrává entita z DB @PreUpdate, @PostUpdate, před a po volání UPDATE na databázi. Tj. pouze pokud je entita pozměněná. @PreUpdate a @PostUpdate, když jsou volány settery @PostLoad, když se provádí refresh

14. Callback metody - seznam signatura: void nazevMetody()

15. Posluchači entit • Zpracování událostí v životním cyklu entit lze separovat do speciálních komponent – posluchačů • Vhodné, když se logika v callback metodách přímo nedotýká entity • Posluchač je POJO s metodami označenými anotacemi z tabulky na stránce 5 • Signatura metody: void nazevMetody(Entita e) • Posluchači se nasadí na třídu entity pomocí anotace • @EntityListeners

16. Posluchač PhotoLogger

17. Konfigurace posluchače Pomocí anotace @EntityListeners Alternativně v orm.xml. Vhodné pro ladění.

18. Generický posluchač entit • Není vázán na jediný typ entity • Obdobné předchozímu typu posluchače • Rozdíl v typu parametru callback metod • java.lang.Object • Lze registrovat jako tzv. default entity listener • poslouchá na všech entitách • možno pouze v orm.xml

19. Jednotka perzistence • Každá entita patří aspoň do jedné tzv. jednotky perzistence • Lze definovat více jednotek perzistence • Každá pracuje s právě jedním datovým zdrojem • Entity lze přiřadit k jednotce explicitně či implicitně • Implicitní zařazení entity • JPA provider skenuje JAR soubor a zkoumá anotace @Entity na třídách • Explicitní • Entity lze pro každou jednotku vyjmenovat v souboru META-INF/persistence.xml

20. Soubor persistence.xml • Obsahuje konfigurace jednotek perzistence v modulu • Modul může být obyčejný JAR nebo EJB-JAR • Umístění v META-INF adresáři modulu • JAR modul může být umístěn • na classpath běžného Java SE programu • WEB-INF/lib • v kořenovém adresáři enterprise archivu (.ear) • v lib adresáři enterprise archivu • EJB-JAR se skenuje při umístění EAR na server

21. persistence.xml - příklad Implicitní zařazení entit, tj. skenování JAR souboru Explicitní vyjmenování entit patřících do jednotky BankTest

22. Získání kontextu perzistence • Nejsnadněji pomocí injektáže • Kontejner podává transakční perzistentní kontext • Pro rozšířený kontext je třeba nastavit atribut type anotace na hodnotu EXTENDED • Kontext lze získat také přes EntityManagerFactory

23. Poznámky k získávání kontextu • Doporučuje se používat injektáž • vymyšleno pro zjednodušení práce • nemusíme se starat o zavírání kontext • nesmí se volat close() • Pokud se použije EntityManagerFactory • programátor musí dbát na uzavírání získaného kontextu voláním metody close() • v prostředí Java SE se objekt továrny získá voláním statické metody createEntityManagerFactory na třídě javax.persistence.Persistence • v Java EE injektáží do atributu anotovaného @PersistenceUnit

24. Práce s objektem EntityManager • Ukládání • Vyhledávání • Aktualizace stavu • Slučování • Odstraňování • Obnova stavu • Uzamykání (v další přednášce)

25. Ukládání entit • Vkládání stavu entity do databáze • Předpoklad, že entita doposud v databázi není • Vytvoří se nový objekt entity • Nastaví se její vlastnosti a relace • Zavolá se metoda EntityManager::persist(entita) • Po vložení se entita stává připojenou ke kontextu • Pokud má entita relace s jinými entitami, může systém vytvořit jejich reprezentaci v databázi společně s hlavní entitou • Kaskádová politika musí být PERSIST

26. Ukládání entit • Při volání persist může být vložení do db (SQL INSERT) odloženo • Pokud dojde k ukládání v rámci transakce, vložení může být provedeno okamžitě, nebo na konci transakce • ovládáno tzv. flush modem: setFlushMode(AUTO|COMMIT) • Mimo transakci lze vkládat pouze pokud je kontext perzistence rozšířený • Vlastní vložení je odloženo dokud se kontext nepřipojí k transakci • EntityManager::joinTransaction() • injektovaný rozšířený kontext se připojuje automaticky

27. Vyhledávání entit • Dva způsoby • podle primárního klíče • vytvořením a provedením dotazu • Vyhledání podle primárního klíče – 2 metody • <T> find(Class<T> entityClass, Objekt key) • snaží se vyhledat entitu podle zadaného primárního klíče • pro číselné typy funguje autoboxing • inicializuje vlastnosti entity podle lazy-loading politiky • <T> getReference(Class<T> entityClass, Objekt key) • vrací objekt třídy T, ale pokud entita neexistuje, při prvním přístupu k objektu se vyhazuje EntityNotFoundException • tato výjimka se může vyhazovat již při volání getReference

28. Vyhledání entity dotazem • Vyhledání možné pomocí JPQL dotazu • EntityManager nabízí tři typy metod pro vytváření dotazu • createQuery • sestrojí dotaz v syntaxi JPQL, který je předán jako parametr • createNamedQuery • sestrojí dotaz podle připraveného výrazu v orm.xml • createNativeQuery • sestrojí dotaz v nativní syntaxi SQL • V EJB 3.1 (JPA 2) nový nástroj: Criteria API • vhodné pro sestavování dotazů za běhu programu

29. Aktualizace entit • V době, kdy je entita připojená ke kontextu, lze na ní provádět úpravy • Operace, které vracejí připojené entity • persist, find, getReference, vyhledání dotazem • Ukládání do úložiště (SQL UPDATE) může být prováděno automaticky (v závislosti na flush-mode) • Lze uložit explicitně voláním EntityManager::flush()

30. Slučování entit (merge) • Metoda EntityManager::merge(entita) • Slučování odpojených entit s kontextem • Pokud entita ještě není v kontextu, je vytvořena plná kopie, která se připojí ke kontextu. • Pokud se již v kontextu nachází entita se stejným primárním klíčem, nahradí se její stav za stav odpojené entity • V obou případech metoda mergevrací připojenou entitu • Je-li kontext rozšířený, lze volat merge i mimo transakci

31. Odstraňování entit • Metoda EntityManager::remove(entita) • Tato metoda nemusí okamžitě vyústit v odstranění entity z databáze (tj. SQL DELETE) • chování se odvíjí od nastavení flush-mode • Po volání remove je entita odpojena od kontextu • Má-li entita nějaké relace, mohou být také odstraněny v závislosti na kaskádové politice • Je-li kontext rozšířený, lze volat remove i mimo transakci

32. Obnova stavu entity • Metoda EntityManager::refresh(entita) • V případě, že si nejsme jisti aktuálností stavu připojené entity, lze zavolat refresh(entita) • Přepíše všechny provedené změny stavem z db • Má-li entita nějaké relace, jejich stav může být také obnoven v závislosti na kaskádové politice • Je-li kontext rozšířený, lze volat refresh i mimo transakci

33. Metody contains a clear • Metoda contains(entita) vrací true, pokud kontext perzistence obsahuje entitu předanou jako parametr • Metoda clear() odpojí všechny entity momentálně připojené ke kontextu

34. Metoda flush • Entity manager rozhoduje, kdy se změny způsobené voláním persist, merge a removepromítnou do databáze • Synchronizaci lze prosadit voláním flush() • Provádí se automaticky před voláním dotazu, který souvisí se změnami v kontextu • neúčinné implementace mohou provádět flush před každým dotazem • výjimkou je find, jelikož hledání podle primárního klíč nemůže být ovlivněno změnami v kontextu

35. FlushModeType • Chování entity manageru lze ohledně synchronizace s databází řídit použitím výčtového typu FlushModeType • AUTO • přednastavené chování, odpovídá popisu z předešlé stránky • COMMIT • změny jsou synchronizovány v okamžiku ukončení transakce (commit) • synchronizace neprobíhá ani před dotazy • používá se pro zvýšení výkonnosti (batch updates) • Nastavuje se metodou setFlushMode(mode) na EM

36. Mapování perzistentních objektů • Párování tříd na tabulky, atributů entity na sloupce a relace v databázi, generování prim. klíčů atp. • Obvykle dvě cesty • Vytváříme schéma databáze podle objektového modelu • Vytváříme objektový model podle existujícího databázového schéma • JPA lze použít pro oba přístupy • automatické generování databázového schéma • automatické generování tříd entit ze schéma (nic moc) • mapování pomocí anotací nebo xml

37. Základní mapovací prostředky • @Table • Potřebujeme-li změnit defaultní mapování třídy entity na databázovou tabulku • Anotace se umísťuje na třídu entity • Např.: @Table(name="ACCOUNT_TABLE") • @Column • Popisuje mapování atributů entity na sloupce tabulky • Anotace se umisťuje na atribut třídy nebo na příslušný getter • Např.: @Column(name="DEPO") BigDecimal deposit;

38. Mapování primárních klíčů • Každá entita musí mít primární klíč • PK mohou být mapovány na jednu či více vlastností • primitivní typy, java.lang.String, složené s uvedených • @Id • identifikuje jednu či více vlastností entity • @GeneratedValue(strategy) • Doplněk k @Id, říká, že hodnota PK se bude generovat • TABLE – hodnota PK je udržována ve speciální tabulce • SEQUENCE – hodnota PK je generována sekvencí • IDENTITY – bude použit sloupec typu IDENTITY • AUTO – volba je ponechána na poskytovatel JPA (default)

39. Generování PK přes tabulku • Programátorem definovaná tabulka, která v každé řádce udržuje hodnotu pro daný PK • Dva sloupce • PRIMARY_KEY_COLUMN – název primárního klíče • VALUE_COLUMN – hodnota počítadla (hodnota PK) • Tato volba generování musí být doplněna o anotaci • @TableGenerator – atributy: • name – název generátoru, odkazu z @GeneratedValue • table – název db tabulky • pkColumnName – název sloupce v tabulce pro názvy PK • valueColumnName – název sloupce pro hodnoty PK • pkColumnValue – název primárního klíče

40. TableGenerator - příklad

41. Generování PK přes sekvenci • Některé DB mají speciální struktury pro generování sekvencí (Oracle) • @SequenceGenerator • doprovodná anotace k @GeneratedValue • name – název generátoru pro odkazování • sequence_name – název sekvence v DB • initialValue – počáteční hodnota • allocationSize – krok alokace

42. Generování přes sekvenci - příklad

43. Složené primární klíče • Někdy je zapotřebí, aby se PK skládal z více primitivních hodnot či řetězců • Složený klíč je reprezentován tzv. třídou PK • tato třída je přiřazena k entitě anotací @IdClass • @IdClass(třída_pk) • Třída PK musí být • serializovatelná • musí veřejný no-arg konstruktor • musí implementovat hash() a equals()

44. Entita se složeným primárním klíčem Vyhledání podle složeného klíče:

45. Třída primárního klíče - příklad

46. Mapování vlastností entity • @Transient – označení neperzistentních vlastností • @Basic, FetchType – mapování primitivních typů • @Temporal – mapování časových vlastností • @Lob – mapování objemných dat (BLOB, CLOB) • @Enumerated – mapování výčtových typů • @ElementCollection – mapování kolekcí primitivních typů a řetězců

47. Mapování neperzistentních vlastn. • Někdy chceme mít ve třídě entity vlastnost, kterou si nepřejeme ukládat do databáze • Označíme ji @Transient

48. Mapování primitivních typů • Mapování lze řídit anotací @Basic • fetch – strategie načítání hodnoty; enum FetchType • LAZY – hodnota se nahraje při prvním přístupu • EAGER – hodnota se nahraje při ihned • optional – pokud je true, sloupec je chápán jako nulovatelný (nemusí obsahovat žádnou hodnotu)

49. Mapování časových vlastností • Časové vlastnosti lze mapovat do sloupců typu date, time a timestamp • By default se volí timestamp • @Temporal(type) • enum TemporalType • DATE • TIME • TIMESTAMP • Lze použít spolu s @Basic pro zadání parametrů fetch a optional

50. Mapování objemných dat • JDBC definuje typy Blob a Clob pro objemná binární, resp. znaková data • Pomocí anotace @Lob lze mapovat vlastnosti entity na tyto typy • pokud je typ vlastnosti char[], Character[] nebo java.lang.String -> Clob • pokud je typ byte[], Byte[], nebo java.lang.Serializable -> Blob • Anotaci lze kombinovat s @Basic