ORM in the realworld

I am begining a new project that i think will last for some years. Am in the point of deciding the ORM framework to use (or whether to use one at all). Can anyone with experience tell me whether orm frameworks are used in realworld applications. The problem i have in mind is this: The orm tool will generate for me tables and columns etc as i create and开发者_Go百科 modify my entities. However, after the project has gone live and is in production, certain database changes will not be possible. Can this hinder the advancement of the project. If i had used a framework like ibatis for example, i know i would only need to adjust the sql statements based on the database changes. Can someone tell me whether ORM tools have survived the live environment. At my office, we use java based ERP that was done long ago and it was never done using any ORM framework.

Regards. Josh

Only use auto generated schema's for the early development and prototyping. The generated DDL will almost never satisfy any experienced DBA. Further the database is properly going to live longer than the current application code, so spending time on its design is usually well worth the effort.

When choosing a mapper go for a flexible one and stay clear of the object-obsessed mappers, since these often only supports limited database customization. Hibernates poor stored procedure integration comes to mind, as does JPAs lack of support for custom type mappers.

Object mappers like IBatis and EclipseLink are safe choices as they allows you to map almost anything, ensuring that you can create both a great domain model and a nifty schema design. Also note that Spring JDBC has come a very long way (in particular the very handy SimpleJDBCTemplate), so while technically not a ORM it does allow you to do anything you want without writing tedious JDBC boilerplate code.

ORMs are used very widely in real-world applications. The schema change issue you mentioned is typically dealt with in one of two ways:

1. As suggested by earlier answers, you can maintain the schema manually in the database and have the ORM update its schema to match what it sees in the database.

2. You can have the ORM check the database's schema against its own information about the object model and generate the necessary queries to update if there have been any changes.

In my experience, any decent ORM should be able to handle #1 and most seem to be able to manage #2, but it's not quite as universal.

As for which is better, well... That depends a lot on how you view the relationship between your database and your object model.

If your primary interest is on the database and you use an ORM to provide an OO wrapper around the tables and fields to make them accessible more easily, then you'll probably want to go with #1 and keep full control over the database.

If, on the other hand, you view the object model as supreme and are primarily using the database as a dumb persistence mechanism, with the ORM serving to simplify that task, then you'll probably want to use #2 so you can focus on the object model and not have to worry about the underlying database details. Or you might want to take a look at key/value stores, object-graph persistence engines, or other forms of NoSQL databases in order to get better support for straightforward object persistence without having to worry about schema changes on the database side at all.

I have used for several years in production Hibernate + JPA. I have never relied on the ORM schema generation though and I think that this is bad practice in general since you're not totally in control of the schema this way and ORM will not always generate the optimal schema. Using something like Liquibase for tracking schema migrations in a much better idea IMO.

I have been using Hibernate for a few years now, and I am very happy with it. I use the schema generator only to create a brand new database, but for upgrades, I use man-made sql scripts.

I don't think it is possible to reliabily automate the upgrade of the schema: if you rename a field for instance, an automatic tool would remove the field and add a new one, thereby losing content.