The two dozen ORM frameworks listed on java-source.net don’t even count the numerous homegrown ones used so passionately by their makers that they’re blind to all the other crap that’s out there. There’s simply too many bored developers trying to come up with a specific solution to a general problem and if it weren’t for Hibernate, who managed to somewhat thwart this growing resistance against writing queries, we’d have more ORM frameworks than MVC frameworks.
Anybody who still manually opens a Connection to a database and stuffs their beans by plunging through a ResultSet probably knows that they’re about five years behind where they should be. I’m no historian but to me the ORM boom started with JDO which to it’s credit, did give the idea a sort of legitimacy. It’s just too bad that the implementations were painfully slow and discounted so many scenarios that you ended up creating exceptions on almost every semi-complicated business operation. So what started promisingly as a step in the right direction yielded products like Java Ultra-Lite Persistence which – get this – wants you to write your mappings in Java code! Let’s substitute Java code that executes queries with Java code that creates mappings and then write additional Java code to use those mappings. It’s crap like this that comes out when developers are looking to satisfy their most immediate and gratifying needs.
No ORM talk is worth anything without a mention of IBatis. IBatis is a nice little innocent tool for those who’d rather write their queries in XML files rather than Java code. You’re still writing the queries but they’ll load the dependent objects for you provided you be nice and have the ability to know their source code like the back of your hand. It gained popularity largely because it stopped you from having to concatenate strings in your classes anymore. Lack of stored procedure support was an early issue and you just needed to write one too many handlers to support the data model, unless you were making it from absolute scratch. And besides, we developers are a spoiled bunch, we don’t want a framework to do some work for us, we want it to do all the work. IBatis tried to lessen the workload and did so to some degree but in the end the chances of you screwing up a query in IBatis is the same as if you were writing it in Java. I remember an IBatis committer once swearing on the mailing list that if he’d ever need to start a project, he’d use IBatis and Struts (this is when Webwork was out). I wonder if he still stands by his stance. IBatis has a slower learning curve than Hibernate which won over many a developer, including myself – for a short period of time.
Going off on a tangent now but if you use IBatis.NET – IBatis’ port for .NET – consider yourself lucky, because it appears that IBatis is almost exclusively focusing on their .NET product. The funny part about IBatis.NET is that half the questions on the mailing list pertain to getting Log4Net to log ANYTHING ANYWHERE. I too am guilty of starting one thread on the issue. May God forgive me.
I’m somewhat thankful to Sun for realizing that they dropped the ball on ORM and legitimizing Hibernate as a ground-breaking product by essentially copying them, adding annotations and slapping the label of Java Persistence API on it. The great part about this is that it puts an end to the joke that was CMP in pre-3.0 EJBs. Maybe now that ORM support is built-in to Java, I’m praying there won’t be half-thought-out products, worn-out XML configurations and “We are the best and greatest ORM framework in the world” chants coming from every direction in the Open Source malls. I’m no great software engineer or even a mediocre one at that, but it only takes a handful of brain cells to figure out that standardizing database access is a good thing and having numerous “choices” in such a practice can only be detrimental to the object.
So if you are even thinking in the back of your mind about writing an ORM framework for any reason, stop! Don’t waste your time, we need you to work on coming up with an MVC framework.