Does an ORM integrate with existing applications or do I not understand?

Question

Assume Hibernate for the ORM.

I'm not sure how to ask this. I want to build an application that can replace part of another. For example, say I have an application with various modules, called the "big" app. This application may handle HR, financial, purchases, skill sets, etc. But maybe, for whatever reason, I don't like the skill set module, but I like the rest of the application. I want to build an app that uses the same database that the rest of the "big" app uses but use my software as the front end for that piece.

I could build my app and have it hit the database directly with no ORM. My question is is there an advantage to using an ORM here. I'm thinking there is because if the "big" app goes away and another app is purchased, we could continue to use my version of skill set because I am using hibernate instead of hitting things directly. I'm still learning but I thought that my application used objects that I named and that in the case I just described I'd have to change my mapping files only or/and my code very little.

Here is another example. I have a legacy application and legacy database. It uses database X. I decide that I no longer like the old terminal emulator application that is used to get the data and that I want a graphical version. I can use hibernate with my application and when I finally decide to get rid of the legacy database and change to the latest Oracle or SQL Server, I can do so with minimal headache? Or is my database going to change so much that it wouldn't have matter anyway (I'm suggesting that upon changing to a new database more information will want to be captured)?

I was hoping for comments, if I am misunderstanding why hibernate/ORM might or might not be a benefit.

Thank you.

Answer 1

Switching from one DBMS to another (ala Oracle to SQL Server) is one thing that using an ORM would certainly make much easier.

As for switching from one "big app" to another "big app", I doubt if using an ORM would help that much. It's likely that the database structure and business logic would be different enough that you would find yourself rewriting lots of code anyways.

Answer 2

I do not think you will have a huge benefit frmo hibernate if the database schema changes to something completely different, you might have to change more than just your mapping - especially if more "structure" is added to the database (tables, column and such schema things). That said, if the database was structured mostly the same way, but lets say just the column names and tables names changes and a couple of tables are merged or something like that - you can get by with just changing your mapping.

But I would really recommend using hbernate for database agnosticity, that's is a pretty easy path.

AND then just because it doesn't exactly helps you if your entire database is changed, it such an incredible amount of other forces, that I would choose that over direct DB access most of the time.

Lastly you could think about using a service-layer such as the repository pattern that abstracs away the data access, so the business of your appilcation wouldn't need to change if the database changes.

Answer 3

You can generate domain objects with Hibernate Tools, if you do that than it will be painless and fast. however if you write all the objects by hand you will die. i think its good idea to rewrite part of the app and get to know hibernate better.

Answer 4

I think it's generally a bad idea to make any decision based on the unknowns versus the knowns. Whether you're deciding on a data access/persistence strategy, what car to buy, or what college to go to, you should put the most weight on the things you know you want today, rather than worrying about what may or may not happen tomorrow.

So when considering ORMs, I wouldn't worry too much about things such as apps "going away" or DBMSs changing (unless that's either already been talked about, or there's a history of this in your company). I'm not saying that these aren't things that will never happen, but rather that they should take a back seat to the generally much more important considerations of maintainability, performance, and developer productivity.

So in short, choose an ORM based on its ability to solve the problems and satisfy the requirements that you have today.