views:

78

answers:

3
+2  Q: 

Migrating to ORM

Stepwise, what would be a good way of integrating Spring and Hibernate into an existing JSF application that doesn't use ORM?

+2  A: 

1) You would need to design the domain model first and then map it to the database. You could use hibernate reverse engineering tools for this.
2) Other option is to manually map your current objects(DTO) to database tables. Since you use JSF, I assume you'd be having some objects currently.
3) Design the Service Layer around the objects.

Spring -
1) You could use Spring to provide hibernate template, provide common services through bean.
2) You can manage the transaction in Spring.

Padmarag
At the moment, I'm assuming there is no persistence mecanism in place and the application is using JDBC only.
James P.
But JDBC is a persistence mechanism.
duffymo
According to wikipedia you're right. I was thinking along the lines of object persistence. It will probably be a good idea for me to ask more details about the existing project before going into wild suppositions.
James P.
+1  A: 

If you've written Spring properly, you should have DAO/repository interfaces. If that's the case, all you have to do is write a new implementation of that interface using Hibernate, test it, and change your Spring configuration to inject it.

ORM presumes that you have an object model in place to map to a relational schema. If you don't, I would advise against using ORM. Better to use iBatis or JDBC in that case.

duffymo
From what you're saying, it sounds like adapting an existing relational database could prove to be a big headache. If the requirement is to go from JDBC requests to Hibernate, what sort of problems do you foresee?
James P.
Hibernate requires an object model and a mapping to a schema that has primary keys on every table. It works best if the schema is normalized well. If any of things don't exist you'll have to work to create them. "Big headache"? Shouldn't be too awful. You're writing Java, so I presume you've got some objects.
duffymo
+1  A: 
  1. I would recommend first to write tests to check your code of your previous persistent mechanism. This code could be used to check the correct behavior of our ORM integration.
  2. As mentioned by other answers, having a clear DAO defined by interface helps to bound the DAO code.
  3. Map the domain objects first, then write your DAO, then your service objects (which take care of large atomic suite of operations by enclosing its in a transaction).
  4. Use persistence mechanism which is vendor-agnostic (JPA is the good and only choice).
  5. Start with one kind of database and stick with it during all the migration. In very uncommon cases, you can meet subtle differences between databases which could be very hard to solve, especially if you're a beginner.
  6. When starting, use automatic generation of database (generateDdl for hibernate subsystem) and then, when things starts to be stabilized, force @Table and @Column annotations to fix name of each column. At this point, write a SQL script which generate the database with empty tables. The reason if to fix your architecture and be sure you're controlling the database organization.

If you're serious about ORM, please look at Java Persistence With Hibernate of Christian Bauer (Manning publications), this is "the bible" about hibernate and JPA on Java.

Kartoch
Thanks. In the case, where there was no previous persistence mechanism, I suppose some adaptation will be necessary between the relational database and the class model. If you have encountered any topics on the subject, I would be very interested.
James P.
The problem is more "how the ORM can be flexible to be adapted to my previous database organization". The answer: it is flexible, but you maybe need to use some hibernate features not directly available in JPA. Once more, i really recommend the book of Bauer.
Kartoch
Just understand that when you choose JPA you're likely to use Hibernate as the implemetation under the covers.
duffymo