Par pripominek na toto tema.
Pro upresneni s Hibernate verze 2.x delam vice nez 3 roky, verzi 3 jsem
jeste nepouzil, Torque take ne.
Hibernate jsem tenkrat vybral po vyhodnoceni vice nastroju (OJB, Castor,
Cayene, DODS), tenkrat se
o nem jeste nikde moc nepsalo, Torque mezi vyhodnocovanymi nastroji nebyl.
Tomáš Procházka napsal(a):
Zdravím.
Ptal jsem se v oficiální konferenci Torque, proč jej preferují před Hibernate a
dostal jsem tuto odpověď od Greg Monroe <Greg.Monroe at DukeCE.com>
I took a quick look at Hibernate a while back and came away with the
impression that it is strongly tied to the complexity of Enterprise
Java Beans. It simplifies EJB operations but still requires a lot of
manual bookkeeping and coding to get started.
Hibernate neni podle me svazan s EJB vubec, vznikl nezavisle jako znacne
jednodussi a presto feature rich
verze OR nastroje oproti EJB entity beanum pred verzi EJB3.
Prave pro tuto jednoduchost a pouzitelnost se tvurci specifikace EJB3
(ktera je uplne nova, je nyni ve fazi dokoncovani)
inspirovali u Hibernate 2.x a take pote vznikl Hibernate 3 ktery muze
slouzit jako zaklad pro implementaci
EJB3 (jak ho pouziva JBoss a rekl bych ze se na to chysta i BEA ve
WebLogicu).
Zda se mi ze Greg tuto historii prilis nezna. Vubec celkem mnoho lidi si
jednu dobu myslelo ze EJB3=Hibernate
a naopak coz samozrejme neni pravda.
So, IMHO, Torque was better because it lets you go from laying
out the tables to using code much faster. Torque's tools also help
support and speed up a lot of the processes needed to go from
development to delivery and then maintaining the application. Things
like:
Having an easily produced common file that describes and documents
your application's data storage schema. (Makes version comparison
a simple matter of comparing XML file versions.)
Mapovani pro Hibernate je take v XML souborech, u Hibernate 3 lze pouzit
i anotace ala EJB 3
cehoz ja osobne ale nejsem tak uplne fanda.
It makes the generation of the SQL scripts to create the DB schema
for your application a snap, regardless of which vendor you are using.
Generovat SQL script umi Hibernate take. Ale jak uz zde nekdo psal,
stejne je vzdy potreba DB schema
doplnit o dalsi veci kvuli vyladeni atp. Ja jsem vetsinou postupoval
tak, ze udelam JavaBeany pro persistenci
(diky Eclipse jde gettery, settery generovat), pote pomoci Hibernatoru
(Eclipse plugin) vygeneruji zaklad
XML mapovacich souboru a ty pote doladim rucne a pote z nich generuji
SQL DDL ktere pak rucne doplnim
o specificke indexy atp. Takto to generuji na zacatku, dalsi mensi zmeny
pak jiz vetsinou delam kompletne rucne
aby se zachovala rucni prace kterou jsem v jednotlivych krocich drive
pouzil.
Hibernate ma i nastroje pro jine postupy, napr. od DB schematu k XML a k
objektum, ty ale moc neznam
a nevim nakolik jsou nebo nejsou dobre.
Podle me ale stejne nastroje nemohou zvladnout vse automaticky
optimalne, stejne do toho musite
zasahovat rucne protoze OR mapovani neni uplne jednoznacny proces a
nektere veci jde delat ruzne pricemz
v nekterych situacich je vhodne pouzit jiny pristup nez v jinych.
Ease of implimenting changes to tables into your code. Just change
the xml schema and rebuild.
To umi torque generovat i zmenove SQL DDL scripty? Pokud ano tak klobouk
dolu uz vzhledem k nekompatibilite
databazi u prikazu typu alter table ;-)
Pri zmenach DB schematu u existujici aplikace je take casto treba
napsat scripty pro upravu existujicich
dat atp. coz je stejne rucni prace.
Ease (but not enforcement) of creating cross DB Server engine code,
so you're application is not tied to a single vendor's implimentation.
U Hibernate toto podle me take neni problem.
Others with more hibernate experience might have different opions. But
I'd say if you don't need EJB support, don't use Hibernate.
Hibernate jsem zacal pouzivat prave proto abych nemusel pouzivat EJB
Entity Beany.
And FWIW, IMHO, after working with a major EJB application for 5+ years
and then developing it's replacement with Torque, EJB is overkill for most
common applications which really don't need 100%, never loose a
transaction due to acts of god. A good clustered Servlet only environment
can give you 99.9+% reliablility without all of EJB's overhead (which is
a real response killer with all it's open sockets between this and that..)
Souhlas, presne proto jsem zacal pouzivat Hibernate. EJB ma podle me
opodstatneni v urcitych
situacich, predevsim pro vzdaleny pristup ke sdilene business logice (at
uz "standardne" pomoci RMI
nebo dnes pomoci ruznych WebServices related standardu).
Oh, and as to performance, one thing that Torque does well is to
supply a nice easy to configure/use connection caching methodogy.
This is a big performance gain for any OM layer since a large part
of SQL transaction overhead is simply establishing the connections
to the DB. You should look at what other OM layers do in this
regard if you are concerned about response time performance.
DB Connection pooling je zaklad, bez toho by byl OR nastroj
nepouzitelny. Krome toho
Hibernate ma konfigurovatelny dvourovnovy caching nactenych
persistentnich objektu.
Nerikam ze Hibernate je nejlepsi a vsepouzitelna modla, uz jsem take v
aplikaci jinak pouzivajici Hibernate
delal nejake prime updaty DB pomoci JDBC protoze to je proste rychlejsi
(ale to je obecna
vlastnost OR mapovani, nejdriv ten objekt proste musite mit v pameti a
tedy ho nacist z DB, pak ho
teprve muzete zmenit a ulozit. To napr. neni vubec dobre pro hromadne
updaty nebo mnoho
jednoduchych update). Pokud se ale nemylim tak v Hibernate 3 delaji
nejakou podporu pro prime
update bez nutnosti nacitat objekty z DB. Jeste jsem se na to ale nedival.
Vlastik
--
Ing. Vlastimil Elias Qbizm technologies, a.s.
vedouci analytik ... the art of software.
____________________________________________________________________
www.qbizm-technologies.cz www.qbizm.cz www.qbizm-services.cz
