To ze je Hibernate svazany s EJB je nesmysl. Hibernate 3.0 umoznuje
pouze to, ze muze byt take pouzit jako EJB 3.0 kompatibilni
implementace. Je ciste na vas jestli pouzijete Hibernate klasickym
zpusobem a nebo pouzijete jeho EJB 3.0 API (EntityManager).
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.
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.
--
S pozdravem Roman "Dagi" Pichlik
/* http://www.sweb.cz/pichlik/ Blog pro kodery */
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
