public class CompetitorDaoHibernateImpl 
       extends HibernateDaoSupport 
       implements CompetitorDao {

  ....

}

<bean id="competitorDao" 
      class="CompetitorDaoHibernateImpl" >
      <property name="sessionFactory" ref="sessionFactory"/>
</bean>

public List getUsers() {
  return getHibernateTemplate().find("from User user");
}

public int getNumberOfUsers() {
 Integer count = (Integer) getHibernateTemplate().execute(
  new HibernateCallback() {
    public Object doInHibernate(Session session)
       throws HibernateException, SQLException {
       Query query = session.createQuery("SELECT count(*) FROM User user");
       return query.uniqueResult();
    };
  });
 return count.intValue();
}

Uložení objektu, který jsme právě vytvořili nebo ho Hibernate považuje za objekt dočasný, není nic složitého, jak si můžeme ukázat na metodě saveUser() ze třídy UserDaoImpl.

public List saveUser(User user) {
  return getHibernateTemplate().save(user);
}

Hibernate otestuje, jedná-li se opravdu o dočasný objekt a uloží ho. Pokud tento objekt získává generovaný identifikátor, tento identifikátor mu je přidělen. Pokud objekt vlastní další asociované objekty, Hibernate je uloží též pod podmínkou, že v mapování je tranzitivní perzistence povolena. Pokud Hibernate vyhodnotí, že se nejedná o dočasný objekt, vyhodí výjimku.

Mazání objektu je opět velmi jednoduché.

public void removeUser(User user) {
  getHibernateTemplate().delete(user);
}

Klasickou prací s daty je jejich aktualizace. Data uložená v databázi vybereme, v uživatelském rozhraní upravíme a uložíme zpět. Pokud pracujeme v prostředí webové aplikace, objekty, které upravujeme v uživatelském rozhraní, jsou objekty odstavené. Hibernate nám však poskytuje možnosti jejich opětovného asociování s Hibernate sezením a uložení jejich modifikovaného stavu. Tohoto dosáhneme pomocí metod update(), saveOrUpdate() a merge().

public void updateUser(User user) {
  //getHibernateTemplate().saveOrUpdate(user);
  //getHibernateTemplate().merge(user);
  getHibernateTemplate().update(user);
}

Jaký je rozdíl mezi těmito metodami? Metodu update() používejme v případě, že s Hibernate sezením není asociovaný ten stejný objekt (se stejným identifikátorem), který ukládáme. Pokud tento objekt existuje v Hibernate sezení, použijme metodu merge(). Metoda saveOrUpdate() dočasný objekt zperzistentní a objekt odstavený aktualizuje. Jinak se chová jako metoda update(). Samozřejmě i zde platí tranzitivní perzistence.

Hibernate za podpory rámce Spring nám poskytuje následující možnosti výběru dat z databáze v podobě objektů.

Předtím, než se vrhneme na dotazovací jazyk HQL, si ještě představme metody load() a get(), které jsou vhodné pro výběr jednoho objektu z databáze.

public Competitor getCompetitorById(String id) {
  return (Competitor) getHibernateTemplate().get(Competitor.class, id);
}

Rozdíl mezi metodou get() a load() je následující. Metoda load() vyhodí výjimku v případě, že záznam v databázi neexistuje. Metoda get() vrací ve stejném případě null. Pokud je záznam nalezen, obě metody ho získají, ovšem metoda get() pouze ve formě neinicializovaného proxy objektu.

Dotazovací jazyk HQL je objektovou náhražkou známého dotazovacího jazyka SQL, podporující dědičnost, polymorfismus a asociace. Hibernate poskytuje pro zpracování výrazu, který HQL představuje, dotazovací API. Tento výraz můžeme reprezentovat pomocí implementace rozhraní Query , které krom vykonání totoho výrazu dále poskytuje metody pro vkládání parametrů a manipulaci s výsledkem dotazu (ResultSet).

Aplikační rámec Spring nám potom poskytuje podporu pro zpracování instance třídy Query pomocí zpětného volání v podobě implementace rozhraní HibernateCallback, jak jsme si ukázali v podkapitole 3.1.

HQL je mocný aparát a má téměř shodnou vyjadřovací schopnost jako SQL. Nyní si ukážeme několik běžných příkladů, na kterých si tuto schopnost ilustrujeme, a současně si také ukážeme některé možnosti rozhraní Query. Všechny tyto příklady jsou v plné verzi dostupné v souboru UserDaoImpl.java, který ilustruje, jak správně používat Query API v prostředí rámce Spring.

Následujícím HQL dotazem vybereme všechny uživatele.

Query usersQuery = session.createQuery("from User user");
List<User> users = usersQuery.list();

Část klauzule SELECT je v tomto případě nepovinná.

Na následujícím příkladu si ukážeme nahrazování pojmenovaných parametrů v dotazech. Hodnoty předávané v parametrech budou ošetřené proti výskytu speciálních znaků. Hibernate samozřejmě vnitřně používá klasický JDBC PreparedStatement.

Query query = session.createQuery("FROM User user WHERE username = :username");
query.setString("username", username);
User user = (User)query.uniqueResult();

Pokud chceme vybrat všechny uživatele na základě jejich role, můžeme to provést následujícím způsobem.

String hql = "SELECT user " +
             "  FROM User user, Authority authority " +
             " WHERE authority.name = :role " + 
             "   AND authority in elements(user.authoritySet)";
Query query = session.createQuery(hql);
query.setString("role", role);
List<User> users = (List<User>)query.list();

Rámec Spring nám také poskytuje pomocnou metodu pro získávání objektů přímo na základě HQL. Je jí metoda find() třídy getHibernateTemplate. I tato metoda umí parametrizované dotazy.

String hql = "from User where registrationKey = ?";
List users = getHibernateTemplate().find(hql, key);

Možnosti jazyka HQL jsou natolik rozsáhlé, že je zde nejsme chopni všechny zachytit. Oficiální dokumentace [12] je však velmi kvalitní a možnosti HQL velmi dobře popisuje.

Hibernate poskytuje API, které nám umožňuje stavět dotazy pomocí manipulace s objekty za běhu bez přímé editace řetězců, tak jak tomu bylo např. u HQL. Pokud naše dotazy vyjádříme pomocí kritérií, tyto dotazy budou lépe čitelné, samodokumentující a jejich syntaxe bude parsovatelná a ověřitelná při kompilaci, ale nic není bez chyby. Pokud toto API použijeme, ztratíme část vyjadřovací schopnosti a síly dotazů HQL.

Dotazování na základě kritérií je reprezentováno rozhraním Criteria. Toto rozhraní reprezentuje strom objektů kritérií (Criterion), které jsou na daný dotaz aplikovány. Rozhraní Restrictions poskytuje statické tovární metody pro vytváření objektů kritérií.

V našich příkladech budeme používat pro reprezentaci stromu kritérií rozhraní DetachedCriteria. Toto rozhraní nám umožňuje sestavovat dotazy mimo Hibernate sezení na odstavených objektech a jeho následné zpracování pomocí metody rámce Spring findByCriteria(). Pokud bychom chtěli použít klasické rozhraní Criteria, museli bychom používat a implementovat zpětné volání rozhraní HibernateCallback, poskytované Springem pro získání Hibernate sezení (viz. třída SportBranchDaoImpl). Jiný rozdíl mezi Criteria a DetachedCriteria není.

Na příkladu výběru regionu ze třídy RegionDaoHibernateImpl si uvedeme použití tohoto API.

public Region getRegion(int level, String codeName) {

 DetachedCriteria criteria = DetachedCriteria.forClass(Region.class);
 criteria.add(Restrictions.eq("level", level))
         .add(Restrictions.eq("codeName", codeName));

 List<Region> regions = (List<Region>)getHibernateTemplate()
                                 .findByCriteria(criteria, 0, 1);

 if (regions.isEmpty()) {
   return null;
 }
 
 return regions.get(0);
}

Jak si můžeme všimnout na ukázce, nejdříve vytvoříme objekt reprezentující strom kritérií (požadavků) dotazu pro danou třídu. Na tento dotaz klademe pomocí továrních metod poskytovaných objektem implementující rozhraní Restrictions omezení. Následně tento dotaz zpracujeme s tím, že má být vybrán právě jeden region, což nám ale nevadí, protože vlastnost codeName je u každého regionu unikátní.

Pomocí kritérií lze udělat velmi kvalitní a čitelné dotazy všeho druhu. V naší aplikaci můžeme najít ukázky dalšího použití dotazů na základě kritérií. Celý přehled možností tohoto API však najdeme pouze v kvalitní dokumentaci [12] nástroje Hibernate.

Hladovou strategii aktivujeme na kolekcích nebo asociacích explicitně tak, že na nich v mapování uvedeme atributy outer-join="true" a lazy="false". Tato kolekce poté bude vybrána společně s objektem, který ji vlastní jedním přístupem do databáze pomocí vnějšího spojení.

<set name="authoritySet" table="USER_AUTHORITY" 
     lazy="false" outer-join="true">
 <key column="USER_ID" />
 <many-to-many column="AUTHORITY_ID" class="Authority" />
</set>

Nyní budou uživatelské role vybrány společně s daným uživatelem, viz. User.hbm.xml.

Za běhu aplikace můžeme hladovou strategii aktivovat jak v dotazech pomocí Query API, tak v dotazech na základě kritérií.

public List<GuidePostCategory> getGuidePostCategories() {
  DetachedCriteria criteria = 
      DetachedCriteria.forClass(GuidePostCategory.class);
  criteria.setFetchMode("signPosts", FetchMode.JOIN);

  List<GuidePostCategory> categories = 
         (List<GuidePostCategory>)
         getHibernateTemplate().findByCriteria(criteria);
  return categories;
}

Při zpracování dohoto dotazu bude vždy vybrána kolekce ukazatelů (SignPost) společně s kategorií, do které patří (viz. GuidePostCategoryDaoImpl.java).

Pro většinu asociací a kolekcí v naší aplikaci však máme nastavenou línou strategii. Líná strategie pracuje na následujícím principu. Pokud chceme vybrat nějaký objekt, nemusíme okamžitě vybrat celý graf asociovaných objektů, nýbrž jsme schopni vybrat pouze tento objekt a asociované objekty a kolekce vybrat až při prvním přístupu k nim. Ve skutečnosti jsou všechny líně asociované objekty a kolekce vráceny ve formě neinicializovaných proxy objektů. Tyto proxy objekty jsou méně paměťově náročné, než objekty plné dat, což je nespornou výhodou této strategie. Velikost grafu asociovaných objektů vybraných při získávání našeho objektu se dá nastavit. Dobrou praxí bývá nastavit všechny kolekce na líné vyhodnocování, což je v Hibernate defaultní nastavení a za běhu toto nastavení případně měnit na jiný druh strategie.

<set name="competitors" table="USER_MANAGE_COMPETITOR" 
     inverse="true" lazy="true">
  <key column="USER_ID"/>
  <many-to-many column="COMPETITOR_ID" class="Competitor"/>
</set>

Na ukázce z User.hbm.xml vidíme klasickou deklaraci kolekce, obsahující všechny soutěžící, které daný uživatel systému spravuje. Na této kolekci je nastaveno líné vyhodnocování pomocí atributu lazy="true". Pokud tedy nyní z databáze vybereme uživatele, kolekce soutěžících, které spravuje nebude vybrána. Vybere se až v momentě zavolání metody getCompetitors().

V naší aplikaci, tak jak je nyní nastavená, bychom této funkcionality mohli využít pouze v datové vrstvě. Líné získávání objektů pracuje s otevřeným Hibernate sezením a to je prozatím dostupné pouze v této vrstvě. Tato vlastnost použití líné strategie ve webových aplikacích založených na třívrstvé architektuře velmi limituje. Aplikační rámec Spring však poskytuje API, které umožňuje Hibernate sezení uržovat aktivní po celou dobu HTTP požadavku. Toto sezení je poté dostupné jak v prezentační, tak i aplikační vrstvě, což je přesně to, co požadujeme.

Rámec Spring poskytuje třídy OpenSessionInViewFilter a OpenSessionInViewInterceptor, které se starají o otevření Hibernate sezení na začátku uživatelského požadavku a na jeho konci jej ukončují. To nám umožní používat líný výběr objektů ve všech vrstvách naší aplikace.

OpenSessionInViewFilter nastavíme ve web.xml následovně.

<filter>
  <filter-name>hibernateFilter</filter-name>
  <filter-class>
   org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
 </filter-class>
</filter>

<filter-mapping>
  <filter-name>hibernateFilter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

Tento filtr je tedy aplikován na všechny požadavky jdoucí na naši aplikaci. Filtr má stejnou funkcionalitu jako interceptor definovaný a popsaný níže.

OpenSessionInViewInterceptor nastavíme v souboru aplicationContext-bussines.xml. Rámec Spring na základě zpracování tohoto interceptoru vytvoří Hibernate sezení a uloží ho do vlákna zpracovávajícího příchozí požadavek, kde je dále k dispozici. Tento postup je nejen vhodný pro netransakční zpracování ale také pro transakce, probíhající nad aplikační vrstvou skrze Hibernate transakčního manažera.

<bean name="openSessionInViewInterceptor"  
class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
  <property name="sessionFactory">
    <ref bean="sessionFactory"/>
  </property>
  <property name="singleSession">
    <value>false</value>
  </property>
</bean>

Konfigurace tohoto interceptoru se řídí několika parametry. Nejdříve ho napojíme na továrnu sezení, která se stará o vytváření Hibernate sezení. Parametr singleSession=false říká, že pro každý přístup k datům nebo pro každou transakci bude vytvořeno nové Hibernate sezení. Nebude tedy použito jedno sezení pro celé zpracování uživatelského požadavku. Každé z vytvořených sezení však bude otevřeno až do konce požadavku.

Tento interceptor poté nasadíme na každý uživatelský požadavek podobně, jako jej nasadíme v naší ukázce na všechny požadavky jdoucí na administrační sekci, viz. applicationContext-admin.xml.

<bean id="urlMappingForAdmin" 
 class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">   
    <property name="order" value="3" />
    <property name="interceptors">
       <list>
        <ref bean="openSessionInViewInterceptor"/>
        <ref bean="requestInterceptor"/>
    </property>
.....
</bean>

Nyní máme vše připravené k tomu, abychom línou strategii získávání objektů mohli používat v praxi.