db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: Torque and iBATIS
Date Tue, 18 Apr 2006 22:51:55 GMT
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.

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.)

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.

Ease of implimenting changes to tables into your code.  Just change
the xml schema and rebuild.

Ease (but not enforcement) of creating cross DB Server engine code,
so you're application is not tied to a single vendor's implimentation.

Others with more hibernate experience might have different opions. But
I'd say if you don't need EJB support, don't use Hibernate.

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..)

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.


> -----Original Message-----
> From: "Tomáš Procházka" [mailto:t.prochazka@centrum.cz] 
> 
>  I have again small question.
> 
>  Why you prefer Torque before Hibernate?
> 
>    

Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are confidential communication
or may otherwise be privileged or confidential and are intended solely for the individual
or entity to whom they are addressed.  If you are not the intended recipient you may not rely
on the contents of this email or any attachments, and we ask that you  please not read, copy
or retransmit this communication, but reply to the sender and destroy the email, its contents,
and all copies thereof immediately.  Any unauthorized dissemination, distribution or copying
of this communication is strictly prohibited.



---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org


Mime
View raw message