Přidat komentář

Níže jsou uvedeny informace o ORM - základní informace.

Kategorizace ORM

• s konceptem persistentního kontextu (jednotka práce, transparentní synchronizace)
  Například: Hibernate, NHibernate, JDO, EclipseLink (dříve TopLink), OpenJPA (dříve Kodo), JPA specifikace
• s metadaty (příkazově orientované, změny musí být explicitně zapsány)
  Například: ActiveRecords (R'o'R)
• s query jazykem
  Například: LINQ (není omezen jen na databázi, též podporuje updaty, ale hlavní účel je dotazování)
• příkazové orientované frameworky na nižší úrovni (nepovažují se za ORM)
  Například: iBatis SQL Maps, Ebean (www.avaje.org)

ORM není typem objektově orientované databáze postavené na relační databází, ale s objektově orientovanou databází sdílí některé koncepty (objekty, dotazy podle kritérií, ...)

Proč uvažovat o ORM?

• Největší výhodou je možnost pracovat s objekty a ne se SQL příkazy. JDBC je velmí nízkoúrovňové API, vyžaduje mnoho příkazů a správu zdrojů. ORM tyto složitost skrývá.
• Typový systém databáze je statický, některé databáze umožňují definovat uživatelské typy ale podpora není tak dobrá jako v programovacích jazycích. ORM poskytuje typovou abstrakci, mapuje datové typy programovacího jazyka na databázové typy a zpět (například cenu s měnou).
• Změna databáze skryté pod ORM není tak častá ale ORM je velmi vhodné pro produkty u nichž si zákazníci určují typ databáze.
• Query Language (QL) pracuje s objekty a ne s databázovými tabulkami. S pomocí kritérií nebo dotazů s příkladem není textový dotaz vůbec použit.
• Většina ORM umožňuje použití nativních SQL dotazů pro optimální výkon nad danou databází. ORM pak umožní namapovat výlsedky dotazu zpět na objekty.
• ORM představují určitou zátěž pro systém, u moderních ORM to ale nepředstavuje nepřekonatelný problém.
• Dobré ORM generují velmi dobré SQL příkazy (znají optimální varianty) a jsou lepší než typický ručně vytvořený dotaz průměrného vývojáře. Ne každý vývojář je zároveň expertem přes databáze.
• Jednotka práce též poskytuje cache první úrovně.

Jaké jsou nevýhody ORM, na co je třeba dát pozor?

• Plnohodnotný OR mapper je velmi komplexní a vyžaduje detailní znalost. Nepoužívejte jej pokud v týmu není specialista na vybraný ORM systém. ORM systém vyžaduje metadata a integraci jednotky práce (transakci) v kódu. Donrá znalost OR mapperu je vyžadována pro porozumění všech důsledků a okrajových případů.
• Použité SQL dotazy nemusí být vždy optimální pro danou databázi a není jednoduché je optimalizovat. ORM stále vyžaduje velmi dobrou znalost jazyka SQL.
• Použití ORM na malé množství tabulek nebo na jednoduché aplikaci není vhodné, přináší pouze další knihovny a konfigurační nastavení.
• Většina OR mapperů neřeší dvousměrné relace, tyto relace musí být provedeny v kódu.

Identita objektu

Většina ORM systémů rozlišuje mezi komponentami (hodnotové objekty) a entitami. Entita má vždy neměnné id, v relační databázi je to primární klíč. Identita objektu někdy též používá primární klíč, ale to je nebezpečné, protože primární klíč nových entit není znám do doby jejich uložení do databáze.

Identita objektu je vázaná na persistentní kontext (jednotka práce, transakce), který též obsahuje cache první úrovně. To znamená že uvnitř tého persistentního kontextu je vždy vrácena stejná instance objektu. Pokud je ale persistentní kontext uzavřen nebo objekt je z něj vymazán, identita objektu není dále garantovaná.

Začít od objektů nebo od tabulek?

Pokud začínáme s novým projektem, začít od objektů je vhodnější. Je však potřeba nezapomenout konzultovat připravený návrh s databázovým specialistou.

I při použití ORM použijte DAO

• Použijte DAO k definování standartních CRUD operací s použitím ORM (přímý přístup nebo použití proxy, session.merge vers session.saveOrUpdate v Hibernate)
• Nemíchejte kód pro persistenci s kódem pro busines logiku. Lazy loading je někdy považováno za zadní vrátka do business logiky, protože transparentně spouští SQL.
• Umožní změnit ORM poskytovatele bez změny busines logiky (v praxi se to často nestává)

Cache

Jednotka práce (transaction) již poskytuje cache první úrovně.

Použití cache druhé úrovně lze doporučit až po vyčerpání všech ostatních možností optimalizace. Ne všechny dotazy z ní budou mít užitek a například cachování dat, které se často mění nebo jsou pro aplikaci kritické nelze doporučit. Cachování může být velmi komplikované v případě, že jsou cache synchronizované nad clusterem a transakcemi nebo když do databáze přistupují i jiné aplikace.

Cache dotazů většinou nejsou velmi efektivní, cache entit a vztahů jsou vhodnější.

Uložené procedury a ORM

Uložené procedury jsou nejrychlejší cestou jak ziskat data. ORM má velmi omezenou podporu pro uložené procedury. Uložené procedury jsou nicméně velmi vhodné pro dávkové zpracování, místo ve kterém ORM řešení neuspělo.