> Asi od toho balíčku očekávám moc.
Je treba zmenit mysleni a myslet v objektech. SQL ma byt uplne
zastineno.
> Na to jak dlouho hledám informace (asi to neumím) mi připadá,
Jde o pracovni navyk - taky mne to slo blbe. Je dobre si koupit nejaky
dobry a aktualni slovnik, napr. Cambridge nebo tak. Zlepsi se Vam
anglictina sama a dr. Google bude Vas kamarad.
> Hibernate řeši zřejmě to stejné ale funguje i pro desktop, nebo to je
> vyloženě webovská záležitost?
Zkuste se podivat i po iBatis - mozna vam sedne nejvice. U vsech plati
(toplink,Hibernate,iBatis) ze se pouzivaji vsude ne jenom na webu.
> Umí řešit i tohle ukládání v kaskádě a zjistit si aktuální hodnotu
> vazebního klíče?
Problem bude v tom jak to mate nakodovane viz dale.
> že kdybych zůstal u starého dobrého SQL, tak to mám dávno hotové.
Pro male projekty je to pravda. Sila ORM je u mnoha entit, kdy se do hry
dostanou dalsi nastroje jako AOP a pak napr. transakce resite
deklarativne (napr. reknete neco jako vsechny metody co zacinaji get
jsou tenhle typ a vyzaduji novou transakci nebo se ucastni stavajici).
Vyhozena vyjimka udela sama rollback atp.
> Nakonec při veškerém úsilí to nepozná, že to má po kaskádě dělá uložit
> s novým klíčem.
Jeste se musite podivat po DAO a POJO:
Klient je POJO - Stary cisty Java objekt, tj. nikdo si s nim na pozadi
nejak nehraje.
Ten by mel mit set/get pro svoje promenne a pro relaci Klient-Adresy
(Taky se tomu rika Entity a ty se prevadi na Value Objekt)
Klient#getJmeno():String // jmeno
Klient#setJmeno(jmeno : String) // nastavi jmeno
Klient#getAdresy():nejaka Kolekce // vraci adresy klienta
Klient#setAdresy(:nejaka Kolekce)
// objektove udelani vazby
Klient#addAdresa(Adresa adresa)
{
klient.getAdresy().put/add(adresa);
adresa.setKlient(this);
}
pak je tu DAO tak delate entityManager.persist delete a atp.
tj.
KlientiDao {
void ulozKlienta(klient)
{
entityMamanger.persist(...)
}
}
No a nekde ve formulari bude te mit
k = new Klient();
..
a = new Adresa(); ...
k.addAdresa(a);
getKlientiDao().ulozKlienta(k);
Trosku na hlavu ne? Ano i Ne. Kazda vrstva resi neco jineho - POJO resi
jak jsou data ulozena (mozna jako DDL) a DAO resi jak se s nima naklada
(DML).
> Co jsem našel je , jak se nastaví relace, ale že to neumí takové triviality
> jsem se nedočetl.
To je alfa a omega vsech problemu s ORM - napoprve nemusi fungovat tak
jak si myslime... i na podruhe, potreti...po stobilliontyprvni :-D
> Takže si nejsem jistý, že se nebudu potýkat s dalšími záludnostmi černé
> skřínky.
> Zlatý starý dobrý SQL.
No a ted si vemte, ze mate annotace, spoustu "balastu" okolo a to vse se
preklada v nejaky SQL dotaz, ktery nebyva optimalni.
> Proč jsem do toho šel byl jediný důvod, že si to postavilo přes binding samo
> tabulku. No ale když jí předhodím list, tak si ji postaví taky. Takže mě
> tohle komplikované nastavování anotacemi tedy moc neuspokojilo.
> Možná na to nemám dost času a trpělivosti.
Kde ORM setri praci je pripad, kdy mate cisty novy projekt a sednete ke
kreslitku UML - napraskate entity ulozite a napise mvn install a ono
samo to udela tabulky, entity, vo, dao, services i jednoduche dotazy
typu findByRok()
Udelate dalsi diagram a samo to vygeneruje webove stranky i s akcemi.
Ukazete designerovy, ten doda par obrazku a klient je ready na prijeti
faktury.
(neverite: ->google -> andromda crud)
PS: toplink neznam, ale doufam ze sem nikoho neuvedl v omyl a pokud se
mylim rad se poucim. Tak prosim nemumlejte si pod vousy a napiste
opravy.
