What are the advantages of using an ORM? [closed]

Answer 1

For a podcast that discusses ORM in detail see the following link. http://se-radio.net/podcast/2008-12/episode-121-or-mappers-michael-ploed

Answer 2

Most databases used are relational databases which does not directly translate to objects. What an Object-Relational Mapper does is take the data, create a shell around it with utility functions for updating, removing, inserting, and other operations that can be performed. So instead of thinking of it as an array of rows, you now have a list of objets that you can manipulate as you would any other and simply call obj.Save() when you're done.

I suggest you take a look at some of the ORM's that are in use, a favourite of mine is the ORM used in the python framework, django. The idea is that you write a definition of how your data looks in the database and the ORM takes care of validation, checks and any mechanics that need to run before the data is inserted.

Answer 3

Personally I've not had a great experience with using ORM technology to date. I'm currently working for a company that uses nHibernate and I really can't get on with it. Give me a stored proc and DAL any day! More code sure ... but also more control and code that's easier to debug - from my experience using an early version of nHibernate it has to be added.

Answer 4

I'd say that if you aren't dealing with objects there's little point in using an ORM.

If your relational tables/columns map 1:1 with objects/attributes, there's not much point in using an ORM.

If your objects don't have any 1:1, 1:m or m:n relationships with other objects, there's not much point in using an ORM.

If you have complex, hand-tuned SQL, there's not much point in using an ORM.

If you've decided that your database will have stored procedures as its interface, there's not much point in using an ORM.

If you have a complex legacy schema that can't be refactored, there's not much point in using an ORM.

So here's the converse:

If you have a solid object model, with relationships between objects that are 1:1, 1:m, and m:n, don't have stored procedures, and like the dynamic SQL that an ORM solution will give you, by all means use an ORM.

Decisions like these are always a choice. Choose, implement, measure, evaluate.

Answer 5

Top Benefits:

1. Database Abstraction
2. API-centric design mentality
3. High Level == Less to worry about at the fundamental level (its been thought of for you)

I have to say, working with an ORM is really the evolution of database-driven applications. You worry less about the boilerplate SQL you always write, and more on how the interfaces can work together to make a very straightforward system.

I love not having to worry about INNER JOIN and SELECT COUNT(*). I just work in my high level abstraction, and I've taken care of database abstraction at the same time.

Having said that, I never have really run into an issue where I needed to run the same code on more than one database system at a time realistically. However, that's not to say that case doesn't exist, its a very real problem for some developers.

Answer 6

I can't speak for other ORM's, just Hibernate (for Java).

Hibernate gives me the following:

• Automatically updates schema for tables on production system at run-time. Sometimes you still have to update some things manually yourself.
• Automatically creates foreign keys which keeps you from writing bad code that is creating orphaned data.
• Implements connection pooling. Multiple connection pooling providers are available.
• Caches data for faster access. Multiple caching providers are available. This also allows you to cluster together many servers to help you scale.
• Makes database access more transparent so that you can easily port your application to another database.
• Make queries easier to write. The following query that would normally require you to write 'join' three times can be written like this:
  • "from Invoice i where i.customer.address.city = ?" this retrieves all invoices with a specific city
  • a list of Invoice objects are returned. I can then call invoice.getCustomer().getCompanyName(); if the data is not already in the cache the database is queried automatically in the background

You can reverse-engineer a database to create the hibernate schema (haven't tried this myself) or you can create the schema from scratch.

There is of course a learning curve as with any new technology but I think it's well worth it.

When needed you can still drop down to the lower SQL level to write an optimized query.