Hibernate Support: Why both DAO and ORM?
FireStorm/DAO is probably unique in being the only Java product named after a core J2EE design pattern.
CodeFutures has long advocated that the Data Access Object design pattern is the key to long-term, sustainable Java persistence.
Now, with the introduction of Hibernate support, the marketing message has changed to generating Java persistence code both DAO and ORM.
So why have we added Hibernate support with the option of not using DAOs?
FireStorm/DAO customers that used the previews of Hibernate support were using a version that automatically generated a DAO tier as well as the Hibernate persistent classes and a Hibernate mapping file (*.hbm.xml) for each database table. However, if you think about it for even a few moments, that test market was already pretty much sold on the idea of using DAOs. If you look at the FireStorm/DAO testimonials - all provided without any guidance from CodeFutures regarding content - you'll see that the DAO architecture is the second most popular reason for buying FireStorm/DAO (after productivity).
So not surprisingly, existing FireStorm/DAO users want to use DAOs with Hibernate.
But then we started looking for experienced Hibernate users. And it turns out there's market demand for generating straight Hibernate code - ORM style, without DAOs. The market for FireStorm/DAO without the DAO seems to be divided into a few groups:
-Hibernate users that already have a database - and find it much easier to simply reverse engineer the database than produce objects then map them to the schema
-Hibernate users that are novice developers and find Hibernate difficult to use (actually, all developers have a certain learning curve with Hibernate - FireStorm/DAO just reduces it from a couple of days to a couple of hours)
-Hibernate users in CodeFutures core market - large corporates and IT consultancies. Time is money for these guys and FireStorm/DAO saves a lot of time. A few years ago, the group would not have considered many open source products like Hibernate. But MySQL, JBoss, Red Hat, and of course, some Apache projects, have changed all that.
We've also made DAOs optional with our JDO code generation.
What CodeFutures suggests to Hibernate users is that they look into the benefits of DAOs and at least try it once. After all, they don't actually have to write any of the DAO code!
PJ Murray
CodeFutures Software