Hibernate version: 2.1.8

Hello,

Our current application architecture exists of a Session Façade (SLSBs) which dispatches requests to one or more local business objects (SLSBs). These business objects communicate with data access objects (DAOs) trough fine-grained interfaces. The data access objects are hand-written and contain SQL statements and calls to stored procedures (a Data Access Helper is used to abstract the low-level JDBC tasks).
We would like to start using Hibernate because of the better maintainability and the reduced code complexity in the data access layer. Currently, we are investigating the different possibilities to integrate Hibernate in our application architecture.
We decided to use Hibernate for every new project that will be started from scratch in the future but we already have a lot of EJB-modules which are in development and need to be extended from time to time. Some of these modules contain lots of hand-coded DAOs and we don’t want to replace every JDBC DAO by a Hibernate DAO. Nevertheless, we would like to extend these modules with new Hibernate DAOs in stead of new JDBC DAOs.
Is it possible to combine Hibernate with these hand-coded DAOs whithout duplicating the persistence logic? It’s not the intention to make POJOs for entities that are already accessible through JDBC because that would increase the maintenance cost when the DB schema changes.
I expect several problems with this approach. For instance:
- foreign keys to entities, represented by legacy DAOs, aren’t available as POJOs
- the legacy DAOs can bypass the Hibernate cache resulting in stale data
- …
Are there best practices (or frameworks) to use this mixed persistence strategy? Or is it just not a good idea to try this?

Thanx in advance,
Kind regards...

mmm - I think Hibernate works best when you have a rich domain model.
In your situation, there are different options. What you choose is of course upto you depending on your own set of trade-offs and personal preferences.

-1- Use SLSBs for transaction demarcation, and maybe some workflow logic. Let them delegate the actual domain logic to Hibernate POJOs. The aim must be to make the SLSBs as thin as possible. These POJOs shouldn't really know they are being used from an SLSB context. Assuming you are using some kind of DAO factory, i.e., your DAOs are coded to interfaces, it should be trivial for your SLSB to use HibernateDAOs to load, save these POJOs

-2- Use Middlegen or something to generate metadata mapping (*.hbm.xml files). Use hbm2java to generate *dumb* Hibernate POJOs. Hand-tune mapping and POJO source as you see fit (this would make round-tripping more painful, but that may not be important to you). Retain business logic in your SLSBs, and use the DAOs to load and store these POJO data objects

-3- Upgrade to Hibernate 3; use Hibernate like a JDBC framework (like Clinton Begin's iBatis) to take away the pain of maintaining your DataHelper class; Hibernate will take care of the result-set mapping.

There are probably others, but these should be enough to set you on your way. FWIW, my personal preference would be option -1-
HTH
Satish

(Note: If you are just getting started on Hibernate, it's probably a good idea to move to Hibernate 3 right away rather than start with 2.x)

Satish,
first of all: thanx for your reply!



Personally, I also like this option the most. The problem is that I will have to replace all existing JDBC DAO code by HibernateDAO's and extract the business logic from the SLSB business objects and place it in the POJOs (if I understand u correctly). It shouldn't be really a problem for small or new applications, but I'm talking about more then 60.000 LOC in the current JDBC DAO layer that has to be replaced. (It's hard to sell to my boss).
We decided to follow this option for all new modules.



With this approach, I don't have to change anything to my SLSB business objects (which saves me a lot of time :)) but I still have to write the mappers and modify my DAOs, so they can persist the POJOs with Hibernate (again, those 60.000 lines of JDBC code, pfff, I wish they didn't exist :))



Sounds nice, since we're starting with Hibernate, it might be useful to move to Hibernate 3 right away but I was told this version makes use of some new JDK 5 features (like generics or annotations) which aren't supported by our app server (we're using Oracle 10G App Server). I must confess I haven't investigated this, though... Are there any limitations with using the new-and-improved Hibernate 3 when used in the 'older' environments?

I've just re-read my reply and I'm starting to think I want to do things that, technically, are just not possible... I think I have to choose between either migrating to Hibernate (as a whole) or staying with my old-school JDBC DAOs... If I could turn back time, a few years, I would have chosen to use Hibernate immediatly... ;-)

Anyway, Thanx for your help...

Greetz,

Stijn Janssens

Nope - both mapping files and POJO source can be auto-generated. Not sure what "mappers" you mean. Yes, you need to rewrite your DAOs (they'll be simpler, trust me ;-). What did you expect, magic ?
:-P



For core hibernate functionality, no. JDK 1.3+ should be fine.
For annotations, you'll need JDK 1.5 or maybe an annotation pre-compiler (google for it).
Either way, you can live without this happily for the time-being as annotations are neither mandatory nor production-ready (for the moment).


Not completely true - you *should* be able to mix and match by changing some code, esp. in DAOs. This should be especially easy if you choose option -3-


NP - glad to have been of help.
Satish