Should I Or Should I Not Use ORM ?

I have seen that developers in general, have a whole lot of strong opinions about ORM. When you see so many passionate, conflicting opinions in so many different places, it’s a pretty clear sign you’re looking at a religious argument rather than a rational debate. And, as in any good religious argument — vi or emacs — this one has two sides, too.

I started off my career building a large scale enterprise web application that was built on Rails, a web application framework developed in Ruby that supports ORM using the Active Record architectural pattern. Since then, I have had the opportunity to work on projects that dealt with data the non ORM way too. And I felt I should probably share my understanding, or rather my views on the whole ORM non ORM debate.

The ORM debate isn’t about technology; it’s about values. People tell you that you should or shouldn’t use ORM based on what they think matters more: clean data access, or clean code.

• The first camp — thinks that software should concentrate on the model level and treat the data store as incidental. People in this camp say you should use ORM because it lets you describe at a high level how your program’s data should be stored and retrieved from the database with little code using the language of the program without making the model “leak” SQL.
• The second camp — thinks that software should concentrate on the persistence level and treat the code as incidental. People in this camp don’t use ORM because they think the program should be written so its data storage and access patterns fit naturally with the underlying data store, and all data access is controlled and explicit.

So Who’s Right?

No one is right, and no one is wrong. Both camps have good points and bad points, and both approaches can lead to good and bad code. But in the debate, most people choose a side based personal preferences and values rather than evidence.

So here are some best practices from both camps:

• If you’re going to use ORM, you should make your model objects as simple as possible. Be more vigilant about simplicity to make sure your model objects really are just Plain ol’ Data. Otherwise you may end up wrestling with your ORM to make sure the persistence works like you expect it to, and it’s not looking for methods and properties that aren’t actually there.
• If you’re not going to use ORM, you should probably define DAOs or persistence and query methods to avoid coupling the model layer with the persistence layer. Otherwise you end up with SQL in your model objects and a forced dependency on your project.
• If you know your data access patterns are generally going to be simple (like basic object retrieval) but you don’t know all of them up front, you should think about using an ORM. While ORMs can make building complex queries confusing to build and difficult to debug, an ORM can save you huge amounts of time if your queries are generally pretty simple.
• If you know your data access pattern is going to be complex or you plan to use a lot of database-specific features, you may not want to use an ORM. While many ORMs (like Hibernate) let you access the underlying data source connection pretty easily , if you know you’re going to have to throw around a lot of custom SQL, you may not get a lot of value out of ORM to begin with because you’re constantly going to have to break out of it.
• If it absolutely, positively, has to, has to, has to go fast, you may not want to use ORM. The only way to be absolutely sure all your queries consistently go fast is to plan your database structure carefully, manage your data access pattern with extreme prejudice, commit to one data store, and write your own queries optimized against that data store.

Having mentioned some of the scenarios depending on which you could decide on whether or not to go with ORM, let me also point out few Pros and Cons of ORM in general.

PROS

• Facilitates implementing domain model pattern.
• Huge reduction in code.
• Takes care of vendor specific code by itself.
• Cache Management — Entities are cached in memory thereby reducing load on the DB.

CONS

• Increased startup time due to metadata preparation( not good for desktop applications).
• Huge learning curve without ORM.
• Relatively hard to fine tune and debug generated SQL.Not suitable for applications without a clean domain object model.

Whether or not you should use ORM isn’t about other people’s values, or even your own. It’s about choosing the right technique for your application based on its technical requirements. Use ORM or don’t based not on personal values but on what your app needs more: control over data access, or less code to maintain.