Link Details

I prefer JDBC or Apache iBATIS. I've worked with Hibernate for eight months, after inheriting a mess of a project. The original developers designed a very poor database schema, which made Hibernate extremely difficult to use, and thus look bad. I found myself asking, "Why is it doing that?" "Why won't it do what I want it to do?" "If I were using SQL and JDBC, this would be finished already." We weren't allowed to rewrite anything or redesign anything because of a lack of funding and a production deadline to meet. Working with Hibernate is like working with a black box: you have no idea what's going on in there. Now, with SQL, you know exactly what you're getting. SQL is the most popular, most common, and easiest way to communicate with a database. Why are we moving away from it? What is up with Java developers chickening away from SQL?

eg71209 - you can use SQL with Hibernate. Using Hibernate is NOT moving away from SQL. It is not about "chickening away" from SQL. Pick up a Hibernate book (by the developers of it) or the FAQ on their website and read about the beginnings of Hibernate.

Avoiding SQL clutter in code is simply a matter of organization. We put SQL in files using a folder hierarchy where the root is the database type and then wrote some code to find the SQL based on names. It took about 2 days of effort and solved us having to lug around 15 megs of junk hibernate jars. Sorry but Hibernate has no reason to exist.

Too funny. It is more than just SQL clutter. It is also transaction clutter and so forth.

If your needs are simple or your db design is just too difficult to translate to OO objects, then Hibernate might not be the right choice. It sounds like in your case iBatis might have been better.

I have used Hibernate in simple and complex applications. In all cases, it has been better than hand coding the SQL.

@jwenting We all know that Hibernate uses SQL under the hood. It is dynamic SQL. At the large companies I've worked as a consultant, most of them demand optimized SQL, and are against dynamic SQL. Yes, Fortune 500 companies with architecture teams that say "no" to Hibernate, and I agree with them.

Yes, SQL is not OO. So, what? Let's make everything OO, shall we? Let's make PHP like Java. Hey, here's a thought: PHP is not Java. Let's make JavaScript just like Java. Here's another thought: let's just use it the way it is.

Abstraction is good... only when there definitely and clearly needs to be abstraction--not when you want to abstract the hell out of everything.

Regarding switching databases, how often do companies, both large and small, switch databases? Very rarely. "Hey, it's been six months now. Let's switch to MySQL for fun. Ya know... to test this Hibernate thing we've implemented because it's new, hot, database agnostic, and the developers don't need to know SQL." Gimme a break.

"The argument, 'If we just did X, we'd have used far less time' is commonly heard used by people who don't regularly work on large projects and/or never have to maintain existing code bases." Dicto simpliciter here. Making that generalization is fallacious. There are other causes for people saying this, such as that person being more knowledgeable, more interested in providing value to the company, or the existing project was poorly designed because the original developers wanted to play with new toys to put on their CV.

So, using JDBC and SQL is the cause of cluttered code? Non sequitur. Your statement is fallacious because there is a missing step, a causative link. "The developer uses JDBC and SQL. The developer is disorganized, inexperienced, and ignorant. The developer has cluttered code." The second sentence was missing. Assuming that all developers who use JDBC and SQL have cluttered code is wrong.

Regarding opening and closing connections, we have connection pooling with Apache Commons' DBCP and the "Template" design pattern (Spring Framework's JDBCTemplate, or write your own).

@eg71209 - As I replied, you can use hand coded SQL with Hibernate. I know of at least one person (discussion here or serverside) who TOTALLY uses it with Hiberante/JPA.

I don't know what companies you have worked at, but just be cause they demand things, doesn't mean they are correct. They just don't know any better. Most "architecture teams" are clueless. Sad but true.

I don't see how Hibernate and JPA and now LINQ can be so popular if the big companies are not asking for it.

Hibernate is NOT trying to make SQL OO. It is about getting back and forth from OO to Relational.

As for switching database vendors ... the main reason is because the cannot because of people like you. I've it at least once for the production database. And many times have used one database in test and another in production.

Sometimes using JDBC/SQL is the right thing to do.

@mknutty Yes, you can use native SQL with Hibernate. Then, why use Hibernate at all?

"At least one person... who TOTALLY uses it with Hibernate/JPA." Argumentum ad numerum. One or more people using native SQL with Hibernate does not make it right.

I have worked at Discover Financial Services, Fitch Ratings, Tribune Interactive, and Northern Trust. All of them are large companies. "Just because they demand things, doesn't mean they are correct." True, but, in the professional world, usually there are many good reasons for these demands. "They just don't know any better. Most 'architecture teams' are clueless. Sad but true." Wow! You must have extensive experience with working with so many architecture teams in many companies, both large and small, for you to make such a conclusion.

"I don't see how Hibernate and JPA and now LINQ can be so popular if the big companies are not asking for it." Argumentum ad ignorantiam. "A" is so popular; therefore, "B" must be asking for it. You do not know that big companies are asking for it. There are many small companies. Also, there is a difference between popularity from "buzz" and popularity from usage.

"As for switching database vendors ... the main reason is because they cannot because of people like you." False. That is not the main reason why many companies choose not to switch database vendors. Other reasons: pleased with initial selection of database vendor due to thorough research, a change does not provide value, a change will incur costs that exceed the benefits, etc.

From your statements, it seems that you have not worked for many large companies, maybe no large companies at all. For those who have, we understand the bureaucratic procedures and the many different types of costs (transition, opportunity, etc.).

@eg71209 - Look at your statements, then the answers and then, maybe, you might understand the answers.

"SQL with HIbernate" - occasionally you need to code sql instead of Criteria/HQL. Why toss out a good thing when you only have few, if any exceptions.

"Argumentum ad numerum" - Look it up before you use it. Anyway, my point was that it was possible and that that using Hibernate doesn't mean no SQL. I wasn't even pointing out that it was "right" (I don't think it is). I was pointing out that you were pretty much clueless about Hibernate.

"You must have extensive experience with working with so many architecture teams in many companies, both large and small, for you to make such a conclusion. " Yes i do. And i am in contact with others who do too. I see the same thing over and over.

"Argumentum ad ignorantiam" - What do you call your fortune 500 argument? Anyway, wrong usage again.

"That is not the main reason why many companies choose not to switch database vendors." Really? What i hear is that is would cost too much and that they used Stored Procedures ...

":pleased with initial selection of database vendor due to thorough research" - They might be pleased initially. Many companies (especially big ones) use more than one RDBMS. And sometimes more than RDBMS. Again, not saying that is a good thing. Anyway, how many technical choices are really made by those in the know as opposed to "on the golf course"?

" , a change will incur costs that exceed the benefits, etc" My point exactly.

"From your statements, it seems that you have not worked for many large companies, maybe no large companies at all. For those who have, we understand the bureaucratic procedures and the many different types of costs (transition, opportunity, etc.)." LOL. What is some fancy legal phrase for "I worked at big companies and they agree with me (at least the department I worked in) so you must not have worked in large companies."? I have worked in many large companies. I've worked on Mainframes to PCs. From COBOL to Java/C#. On VSAM, IMS and RDBMS. I understand the "bureaucratic procedures" and "costs". I don't know why this discounts what I say. The problem is you seem to be a developer minded and not architect minded. You claim i am not looking at the bigger picture when it is you, by your "arguments", that actually is not.

Come to think of it, The first place i worked at were programming was my official job - we used a layer to abstract the database layer. The coding was done in Pacbase (generated COBOL) and the databases were IMS and DB2. Done by one Fortune 500 company for another. LOL.