Gavin King of Hibernate / JBoss Fame sums up why I avoid all OR tools including Hibernate. What if I want to use the full features of my database and write some real queries and not get "certified" in your OR tool? Sure databases should be refactored, but it sounds like he is nicely describing the trap of OR tools: bow to the OR tool - just make it easy, don't resist! And watch the insanity slowly begin . . .
Hibernate and their ilk impose all sorts of crap on you, get their hooks in you, and slow bleed you to death.
In experience hands, they are fine - great, got, been there, done that.
I just don't see what is so wrong with JDBC (Spring JdbcTemplate if you are feeling frisky).
He goes on:
Relational databases are an integration technology, not just a persistence technology. And integration is important. That's why we are stuck with them.
Sad, true in some places, but we certainly don't want this to be the case right?
People are spazing out the most the last year or two about iBatis - apparently less invasive. I'm sure it is. I looked at it a year ago and indeed it looked less evil. I'm just too jaded I guess ... and I just don't get what is so wrong with writing JDBC.
Via Buko Obele
1 comment:
I read somewhere the statement that we solve all problems in software by adding another layer of abstraction. I've seen this happen with interaction with the database, too. When embedding SQL in our code became too difficult, we added the abstraction of ODBC/JDBC. When that became too difficult, we added EJBs. Et cetera, et cetera.
I agree that just using SQL, especially through JDBC, doesn't seem difficult enough to warrant the extra overhead of another layer of abstraction. (My analogy is that it feels like drinking a milkshake through a half dozen straws fit together like Shaggy and Scooby do.) One could also argue that assembly (or C or C++ or...) isn't difficult enough to warrant the extra overhead of the Java abstraction. To me it's all about the cost-benefit ratio.
There are some Jedis that are fine slinging SQL and would prefer to just use JDBC, perhaps with some RAII framework around it. But there are plenty more padawans that will screw it up. From a project management perspective, you have to pick your poison. Like everywhere else in software, you can have wicked efficient code but you need to get some Jedis around. If you want to staff with the first three padawans that show up at the door, you have to make some concessions to the variance in talent.
I'd like to think that J2EE put to rest the notion that we can build a framework that allows non-coders to write code. But the reality is that there are plenty of shops that are willing to trade slower and klunkier code bases for the ability to staff with contractors of dubious skills.
Post a Comment