Re: Spring/hibernate and JDBC
On Jul 11, 4:39 pm, Jack <junw2...@gmail.com> wrote:
Certainly using spring [sic]/hibernate [sic] has a shorter development ci=
rcle than
JDBC and the code is easier to maintain.
Not in my experience. Badly written Spring code, which is all I've
ever seen, is terribly difficult, lengthy and expensive to maintain.
Badly written Hibernate code, which I have seen, likewise. The
majority of Hibernate code I've seen (across several projects that
used it) was all badly written. The problem came about with Hibernate
because people used it in lieu of SQL (i.e., raw JDBC calls) rather
than to support an object model.
Here for efficiency, I mean performance. For a server with frequent
and large amount of database accesses(insert/delete/update), which way
has a better performance?
That depends, and has been answered upthread. Properly used, JPA-
based code (including Hibernate) can be faster than raw JDBC,
depending on the use patterns. Only you can answer this question. We
cannot, based on the paucity of information you provide about your
scenario(s). Your question is like asking, "Which relieves pain
better, aspirin or acetaminophen/codeine?" The answer depends on the
problem you're trying to solve.
The question you should be asking is which one suits your logic
better. Do you need to maintain an object model that must persist?
Chances are that Hibernate is useful and will help you - IF YOU KNOW
WHAT YOU'RE DOING! If you don't, neither Hibernate nor JDBC can save
you.
The key is that JPA (don't use "native" Hibernate!) supports an object-
oriented model; JDBC supports a set-oriented model. When set
operations are needed, JPA gets in the way. When object-oriented
operations are needed, JDBC gets in the way. Use what's right for the
problem. You will never (NEVER!) get a reliable answer to "which has
better performance?" unless you write your code correctly (!),
appropriately to the programming model and MEASURE the performance.
Development and maintenance costs are more important than tiny
differences in runtime cost. You might find that there is no
measurable difference at runtime. Code correctly first, and only
address performance in the face of a demonstrated bottleneck.
Stop repeating your question until you've assimilated the good answers
you've already received, please.
--
Lew