Hi..All,
I am trying to understand Hibernate & how it plays a role in the J2EE architecture.
Earlier we had developed a J2EE application which the following architecture in place :
MVC- > EJB -> DAO-> DB
What I heard from my colleagues (who are also trying to learn hibernate) is that if we redesign the application to use hibernate , it will be like this :
MVC-> EJB - > DAO - > DB
Does this sound right?
Regards
Not in my opinion.
There are four types of EJBs: (1) stateless session, (2) stateful session, (3) entity, and (4) message-driven.
Hibernate can only replace entity beans. So it's not "Hibernate in place of EJBs", it's "Hibernate in place of entity beans".
So your diagram:
MVC- > EJB -> DAO-> DB
Should really be:
MVC->stateless session beans->DAO interface, with Hibernate implementation->DB.
Do you have a DAO interface now that uses entity beans underneath? If so, your redesign is just replacing the DAO implementation.
Have you looked into EJB 3.0 spec and the Java Persistence API (JPA)? Could be a good way to go. I believe JBoss uses Hibernate as their JPA implementation.
%
> I'd just like to mention that a DAO layer is what you
> need in my opinion. I've seen several projects use
> Hibernate and/or migrate to it and all ended
> horribly. I've yet to see a hibernate success story.
> Stay away from it if possible.
Hibernate and DAO layers aren't mutually exclusive.
I've got three production systems that are using Hibernate to good advantage, one of them for over a year.
%
I'm just saying, every time I see a project that migrates to hibernate, I see disaster. Now if you build your app from the ground up with Hibernate in mind, then maybe you can do it without so much pain.
That said, I've never seen a hibernate project do well. I wouldn't recommend anyone use it except for small/simple projects or if you have a lot of patience and nerve.
> I'm just saying, every time I see a project that
> migrates to hibernate, I see disaster. Now if you
> build your app from the ground up with Hibernate in
> mind, then maybe you can do it without so much pain.
Ours used a legacy schema. Hibernate will have problems if the underlying schema doesn't reflect Hibernate's view of "best practices".
> That said, I've never seen a hibernate project do
> well. I wouldn't recommend anyone use it except for
> small/simple projects or if you have a lot of
> patience and nerve.
What's the alternative? Straight JDBC?That doesn't require patience and nerve?
How does JPA change your thinking?
%
> What's the alternative? Straight JDBC?That
> doesn't require patience and nerve?
Yes, implementing the DAO pattern with straight JDBC is a much better solution compared to hibernate IN MOST CASES. JDBC is a standard. I's portable. When there are errors you can actually see them. You can debug through the code. Better performance. Easier to maintain since a schema change doesn't involve a full regen of your code.
> > What's the alternative? Straight JDBC?That
> > doesn't require patience and nerve?
>
> Yes, implementing the DAO pattern with straight JDBC
> is a much better solution compared to hibernate IN
> MOST CASES.
We should spell out what those conditions are.
> JDBC is a standard.
Hibernate is built on top of JDBC.
JPA puts much of what's in Hibernate under the standard aegis.
> I's portable.
Hibernate is no less portable than JDBC and Java.
> When there are errors you can actually see them.
Not sure what this means. When I have Hibernate problems I can see them. They're just different errors that might be unfamiliar.
> You can debug through the code.
You can do this with Hibernate if you attach the source code to your IDE. I can trace into Hibernate or Spring with IntelliJ.
> Better performance.
Not always. I'll agree that the SQL generated by Hibernate is not always optimal, but you have far better control with lazy loading and caching. I'd imagine that writing the equivalent in JDBC would be difficult.
JDBC is certainly a "speed of light" for Hibernate. It isn't likely to be faster, since it's built on JDBC, except for those situations where the cache saves you a network roundtrip.
> Easier to maintain since a schema change doesn't involve a full
> regen of your code.
Not sure how this is a plus for either side. JDBC requires a code change; Hibernate requires a configuration change.
Hibernate won't perform well if the schema doesn't conform to what it considers "best practices". The generated SQL might not be optimal, especially if you have skilled DAs who can write terrific queries for you. In that case, iBatis might be a better choice.
Hibernate won't fix poor schemas that result in table scans, or solve chatty (n+1) query problems without forethought. But JDBC won't, either.
%
We can argue theory all day and compare features, but in the real world your arguments just don't hold up. No offense, but take 2 projects side by side and try both ways, then we'll talk.
Hibernate is for people that don't want to write SQL and need a new buzzword on their resume. Sure, Hibernate does caching, but trying to get the caching to work is another nightmare. Sure, you can debug if you include the source, but who freakin wants to do that?!
Whatever, look Hibernate has 'features', but that doesn't mean they work or the tool is viable. I've seen it bring projects down too many times.
> We can argue theory all day and compare features,
I'm not talking theory. I said I have production systems running, at a Fortune 100 financial institution. Not theory, fact.
> but in the real world your arguments just don't hold up.
Sez you. I work in the real world. That's where my paychecks are cashed.
> No offense, but take 2 projects side by side and try
> both ways, then we'll talk.
Have done it both ways. That's why I'm talking.
> Hibernate is for people that don't want to write SQL
> and need a new buzzword on their resume.
Wrong. I know how to write SQL, and my resume looks fine even without it. I use Hibernate because I think it gives a lift when used appropriately.
> Sure,
> Hibernate does caching, but trying to get the caching
> to work is another nightmare.
I've gotten it to work. No nightmares.
> Sure, you can debug if
> you include the source, but who freakin wants to do
> that?!
Maybe you need a better IDE. It's easy to attach source for a JAR file with IntelliJ.
Besides, how often do you think you have to trace into Hibernate code? It's my experience that problems are with application code or configuration. I've never once had to trace into Hibernate.
> Whatever, look Hibernate has 'features', but that
> doesn't mean they work or the tool is viable.
They work, it's viable. There are a lot of people using it that would disagree with you.
> I've seen it bring projects down too many times.
I'd say it's a lack of skill by those teams. Hibernate is no guarantee, and it's not perfect, but it's not nearly as awful in my experience as you're claiming.
I'll bet their test coverage and quality of tests far exceeds most JDBC implementations.
You've offered nothing in this argument except "I said so". Not very convincing to me, but maybe you'll have better luck with others.
Do these feelings of yours extend to JDO, iBatis, and all other relational database tools out there? You write JDBC from scratch for every app you develop?
%
> I'm just saying, every time I see a project that
> migrates to hibernate, I see disaster. Now if you
> build your app from the ground up with Hibernate in
> mind, then maybe you can do it without so much pain.
>
>
> That said, I've never seen a hibernate project do
> well. I wouldn't recommend anyone use it except for
> small/simple projects or if you have a lot of
> patience and nerve.
I have never seen nor even heard of a technology causing a disaster.
I have seen and heard of many cases where developers chose the wrong technology in the first place and/or the developers implemented the technology incorrectly.
And the chaos of that is multiplied by management which is unwilling to mandate long term planned solutions.
So perhaps your case is very unusual because it is the technology and not the people involved that caused the problems.
-
> That said, I've never seen a hibernate project do
> well. I wouldn't recommend anyone use it except for
> small/simple projects or if you have a lot of
> patience and nerve.
I've seen many "hibernate projects" do well. I saw some others do less well.
I don't think that the outcome of those projects had much to do with the specific use of Hibernate, though.
As for its use in small projects, I'm not sure about the added value here. Why would you go through the trouble of learning a new tool when you'll be only using a few simple SQL statements, if you're not on a pilot project?
Hibernate and other obj-relational mapping tools become more useful when you have large object models, and hence a rather wide object-relational gap.
