recommendations for firestorm dao replacement

I have taken over some code that has been using the Firestorm DAO code generator from CodeFutures. I believe that the license for this is going to be up soon, and was wondering 开发者_高级运维if anyone could recommend any alternatives, open source or not, so that I can get an idea of what's out there to better make a decision.

---

This is probably a bit late for your concrete decision in April, but if you are used to Firestorm DAO, using generated code for every database entity, you might find it easy to switch over to jOOQ. jOOQ omits the "DAO layer" entirely, generating classes that directly represent your relational model. This is generally referred to as the Active Record pattern. Instead of writing DAOs, you can directly query your database from Java using jOOQ's built-in DSL, similar to that of Microsoft's Linq

I agree with JavadocMD, that JPA (or Hibernate) is what is currently considered "best practice". But maybe you don't want to add object-relational mapping to your application for well-known reasons...

---

I would strongly suggest not switching off of firestorm. Firestorm makes writing DAO's a thing of the past for about 90% of the use cases. For all the other cases, just subclass the dao that firestorm makes and add functionality to it that you want, using the inherited helper methods. You don't need a license for this, you can use the free license. No, I'm not from Firestorm, but Firestorm helped me get my project off of the ground with about a 40% time savings. Once I get into more complex queries, it will start saving me about 20% of the dev time, but hey, it's still 20% savings over other solutions. Also, it transforms into raw JDBC. When something goes wrong, it's much easier to debug if you're familiar with ODBC/JDBC.

---

One option would be to completely change directions and go with a persistence framework like JPA. You create your Java object model, add the appropriate annotations, and JPA handles everything else for you without any messy generated code.

Granted, depending on the specifics of your architecture and business situation this kind of change might not be feasible for you. However if you can manage it, JPA seems to be much more in line with current best-practices for Java persistence.

I've used OpenJPA in a production environment: http://openjpa.apache.org/

And we considered TopLink (Oracle's implementation) but ran into a few issues that I can't recall. http://www.oracle.com/technology/products/ias/toplink/index.html