pondělí 18. února 2008

DTO a ORM

Pojem DTO jistě není třeba představovat. Jedná se o objekt reprezentující data, které je třeba přenést z jedné strany na druhou. Asi nejčastějším využitím jest výsledek dotazu z persistentní vrstvy.

Při použití ORM frameworku, jako je např. Hibernate, definuji data v DB pomocí objektů (entit). Tyto entity poté mohou být i výsledkem, tedy mohou představovat jak doménový model aplikace, tak i dané DTO. Jsou ovšem chvíle, kdy takové DTO je nepoužitelné či jeho použití může znamenat výrazný pokles výkonnosti aplikace.

Prvním příkladem, kde entita nemůže (neměla by) být reprezentována jako DTO:
"Vytvoř seznam zaměstnanců s celkovým počtem odpracovaných hodin."
V takovém případě je třeba výsledek z OQL přemapovat do vlastního objektu (DTO), který bude obsahovat číslo, jméno, příjmení, celkový počet hodin. Sice by někdo mohl namítnout, že daná hodnota (odpracované hodiny) se dá do entity, jako @Transient, přidat. Ale doménový model bych se neměl "špinit" vlastnostmi, které reprezentují pouze výsledek nějakého dotazu.

Druhým příkladem je distribuovaná Java. Jinými slovy řečeno, ve chvíli, kdy vzdáleně volám remote EJB, by výsledkem mělo být pouze to, co skutečně potřebuji. Nikoli anotovaná entita, která obsahuje mapované kolekce a dalších X vlastností, které mě v té chvíli nezajímají. Dodržení této zásady bude mít pozitivní vliv na výkon aplikace.

Důvody, proč je někdy lepší použit DTO namísto entity, jsem uvedl. Nyní ovšem přichází otázka, jak takové DTO přemapovávat z OQL dotazů a jak si co nejvíce ušetřit nudného psaní kódu.

První možností je použití klauzule new z JPA. Takové OQL by mohlo vypadat následovně:
public List getList() {
String oql = "SELECT new ZamPocetHodin(z.cislo, z.prijmeni, z.jmeno, x.vypocetHodin) FROM Zamestnanci z .....";
return entityManager.createQuery(oql).getResultList();
}


Jak je na první pohled patrné, je třeba, aby objekt "ZamPocetHodin" obsahoval konstruktor, který obsahuje dané parametry podle daného OQL.
Tento způsob má vesměs samé nevýhody. Osobně mi asi nejvíce vadí samotná absence jakéhokoli refactoringu. Myslím, že v dnešní době neexistuje IDE, které by dokázalo poznat OQL dotazy a validovat je. Dále mi vadí, že parametrem v konstruktoru DTO může být pouze omezený výčet typů. Není možné vracet jiné Entity, či je nějak dále přemapovat. Poslední věc, která se mi nelíbí, je fakt, že píši zbytečně mnoho kódu. Někde definuji DTO a někde ho musím plnit a přitom stále hlídat, zda se mi něco nezměnilo.

Druhou možností je plnění pomoci Hibernate Criteria API:
criteria.setProjection(Projections.sqlProjection(sql + " AS " + alias,
new String[]{alias},
new org.hibernate.type.Type[] {TypeWrapperImpl.getType(/* type */)}));
criteria.setResultTransformer(Transformers.aliasToBean(ZamPocetHodin.class));


Uvedl jsem jen malý kus kódu, který úplně nedpovídá všednímu použití, ale jde o to, že dost často je hodnota v DTO reprezentována nějakým poddotazem, či jiným způsobem, které SQL umožňuje. Je pravda, že v Hibernate Projections si vše mohu dobře nadefinovat, ale výsledkem je poté naprosto šílený kód, který je sice "dynamičtější" a "programovější" než je tomu u JPA, ale za to je složitější.

Jelikož mi nevyhovuje ani jeden z daných způsobů, snažil jsem se nalézt nějaký vhodný způsob, jak se zbavit toho nudného či složitého psaní na přemapování do DTO.
Po pečlivém rozmýšlení jsem se rozhodl, že by nebylo špatné nahlédnout na danou věc stejně jako v případě mé implementace "Irminsul Criteria". O co vlastně šlo, si můžete přečíst zde a zde.
Cílém mého snažení bylo, abych vytvořil DTO objekt, který pomocí anotací nad atributem bude obsahovat dané SQL příkazy, které naplní příslušnou hodnotu. V této chvíli se jedná stále o testování, ale výsledkem mého snažení je již celkem funkční základní část, tedy jednoduché přemapování.

Nyní uvedu malý příklad takového přemapování:
@DTO(entity = EntitaOdkudSeDataZiskavaji.class)
@Aliases(values={
@Alias(associationPath="strediska.provoz", alias="provoz"),
@Alias(associationPath="rj.testPolozky.polozka", alias="polozka"),
.....
})
public class TestDTO implements Serializable {
@ProjectionSQL("(({polozka}.faktura * {vicePraceMena}.aktualni_kurz) * (procento / 100))")
private BigDecimal opravy;

@ProjectionSQL("(({polozkaZakazky}.cena * {mena}.aktualni_kurz) * (procento / 100))")
private BigDecimal cenaVyrobku;

@Projection("pk.cislo")
private String cislo;

// settry, gettry, atd.
}
List result = factory.findForDTO(TestDTO.class);


Jak je z kódu patrné, jde pouze o klasické POJO, které je anotované, aby implementace pochopila, že jde o DTO, které je spouštěne nad danou entitou (@DTO) a obsahuje ty či ony aliasy, které usnadňuj psaní ProjectionSQL.
K tomuto účelu jsem využil implementace Hibernate Projections a ProjectionsSQL, kde podle jasných pravidel převádím dané anotace na projekci, která je již obeznámena s daným typem a tím, co vlastně daný atribut reprezentuje.

Opěvná píseň

Předem musím poznamenat, že toho dané DTO umí více, jednak je to možnost spojit toto DTO i s Filtr objektem, který jsem popisoval ve výše odkazovaných člancích. Výsledkem je pote jednoduche volání:
List result = factory.findByCriteriaDTO(filtr, TestDTO.class);


Již se tedy nemusím zabývat nutností definování filtru a vrácených dat, oba stavy jsou řízeny anotacemi.

Dalšími možnostmi jsou řazení, získaní hodnoty přes alias, či přes vlastní definici, která může být ve formě SQL či OQL zápisu.

Díky tomu odpadá několik věcí:

  • není třeba definovat nějaké metody v DAO

  • nemusí se psát žadné přemapování, stačí jen definice DTO

  • není třeba hledat, jak se dané DTO plní, je to jasné z jeho definice

  • není třeba se bát refactoringu jako v případě implementace přes JPA

  • není třeba určovat vrácený typ jako v případě Hibernate, typ je již jasný z definice atributu třídy DTO



Až bude daná funčnost plně funkční, nabídnu své řešení ke stažení. Zatím bych nerad někde publikoval zabugovaný nedodělek :)

Zajímal by mě Váš názor na takovouto implementaci DTO. Je dost možné, že někdo přijde s lepším nápadem či možností, která již dávno existuje a jen já o ni nevím :)

neděle 17. února 2008

Seam - tipy a triky

Jelikož jsem zastánce tohoto frameworku, z jichž uvedených důvodů, rozhodl jsem se sepsat pár dobrých triků, které mohou pomoci při vývoji s tímto frameworkem. Dnes začnu asi tou nezajímavější a tím je Hot Deploy, nebo-li rychlá aktualizace některých částí aplikace bez nutnosti provádět celé nahrání aplikace na server.

Hot deploy - NetBeans
Netbeans 6.0 má dost slabou, respektive nulovou, podporu pro tento framework. Jednou z dobrých vlastností Seamu je tzv. hot deploy, kde změny na view vrtvě mohou být aplikovány bez nutnosti provádení undeploy-deploy aplikace. Jedná se zejména o změnu facelets stránek. Takže jak něčeho takového dosáhnout v netbeans?

Stačí vytvořit vlastní "ResourceResolver", který se poté zaregistruje v web.xml.
Příklad takového ResourceResolver:
public class FilesystemResourceResolver implements ResourceResolver {
private static final String PATH_TO_DEVELOPMENT = "/home/ales/dev/java/Irminsul/Irminsul-war/web/";
public URL resolveUrl(String s) {
try {
return new URL("file", "", PATH_TO_DEVELOPMENT + s);
} catch (MalformedURLException e) {
e.printStackTrace();
return null;
}
}
}


Poté již stačí uvést registraci do web.xml:


facelets.DEVELOPMENT
true


facelets.REFRESH_PERIOD
0


facelets.RESOURCE_RESOLVER
irminsulweb.FilesystemResourceResolver



Důležitou součástí je to, aby Seam byl spuštěn v debug módu. Toho lze docílit pomocí definice v components.xml:


Díky vlastní definici "ResourceResolver", jsou nyní jednotlivé facelets stránky načítány z cesty, která je uvedena v "PATH_TO_DEVELOPMENT". Pro změnu stačí v NetBeans editovat nějakou facelets stránku, uložit změnu a ve webovém prohlížeči provést refresh.

Tato malá pomůcka je ideální zejména ve chvíli, kdy jednotlivé facelets stránky obsahují různé komponenty (rich faces, ajax4jsf, atd.). Podle toho, co jsem se dočetl v Seam dokumentaci, tak se pracuje i na možnosti provádět hot deploy nad EJB. Otázkou je, jestli tato vlastnost není spíš více ovlivněna aplikačním serverem, než tímto frameworkem.
Takový hot deploy nad EJB se dá sice také provést (v debug modu pro AS), ale jedná se o velice omezené možnosti. Není možné vytvořit novou EJB za běhu, zmenu public metod, atd. Jde tedy čistě o vnitřní implementaci uvnitř business metod. Doufám, že se jednou dočkáme změn i v této oblasti.

Když programátor založí a řídí firmu

Jako malý jsem chtěl být popelářem. Ani ne tak proto, že bych měl nějaký zvláštní vztah k odpadkům, ale hrozně se mi líbilo, jak...