I have started using ORM technology in the last few years. My first exposure was NHibernate. I then moved onto Linq 2 Sql, and Entity Framework.

The issue I have however is, there are some organisations where I have found strong opposition to introducing ORM tools.

They usually have a number of reasons:

  • they have a lot of built up SQL skills in the team, and are worried about the underlying SQL that ORM's generate.
  • they have DBA's who like to be able to see the SQL an app uses in order that can review it for best practice.
  • they are worried about performance (some people have "heard" the ORM's aren't as performant but have no real proof themselves - there may well be some truth in this! :).

So, I'm looking for the best or most convincing arguments that you have put forward FOR the use of ORM tools.

Equally, I would be interested in the against arguments too.

Note: this is NOT a discussion over which ORM I should use.

  • Also, see: programmers.stackexchange.com/questions/69327/…
    – Kramii
    Apr 26 '11 at 3:02
  • 2
    some organizations are opposed of any change. Their motto is "don't fix it if it ain't broken".
    – vartec
    Apr 26 '11 at 11:33
  • 1
    @vartec and Usually those types of organizations are the bane of competent programmers and only retain the dregs/incompetents who also are opposed to change. Apr 26 '11 at 13:59
  • @Wayne: sad but true
    – vartec
    Apr 26 '11 at 14:01

I would say that some projects lend themselves to being easier to work with ORM's than others. My current company has three big things going for it that made ORM a snap decision:

  1. The application is very simple in that it does CRUD against basic objects.
  2. There are very few joins involved when it comes to displaying data back to users in lists.
  3. There is very little record contention and as such, not much decision making had to be put around transactions and the consequence of locking data.

Beyond that, remember, DB people are very risk adverse whereas Dev's are much more risk embracing. This question becomes much more about human psychology.

  • I like this answer a lot. ORMs definitely have positives but a lot of people seem to push it for every situation. I like that you've said that it can indeed work very well, but may not under every condition
    – Mike M.
    Jan 31 '11 at 15:17

We have recently switched over to an ORM based approach and I can give you some negatives, but I'm hard pressed to find worthwhile positives. Most of this is due to the nature of our database.

Pros (note that both of these could be accounted for using SPs, ORMs make them easier, however):

  • When it's something nice and simple, it'll be performant and clean.
  • A lot of logic is pulled out of SPs and can therefore be tested.


  • When it's not nice and simple, the SQL will be garbage. You may not get the data back that you expect. It will be slow and will be incredibly difficult to tune.

  • Our database is constantly changing. That means every couple of days someone needs to spend an hour updating the model to add a table or change datatypes that are changing (agile + ORM on a large constantly changing database is brutal).

  • +1 for A lot of logic is pulled out of SPs and can therefore be tested
    – ozz
    Jan 31 '11 at 15:16

Why does it have to be all or nothing? There's nothing to stop a DBA or database developer to create some sort of view, udf or stored procedure to handle something they feel is overly-complex or they want to have as much control as possible.

There are ways to capture the sql being created.

The performance of the ORM generated sql can be compared to something more optimized.

At some point creating and maintaining code has to be a consideration.


As far as I am concerned, the only legitimate reason I have heard for using object relational mapping (ORM) is if a switch to a different database engine is probable (not just possible). MySQL to Oracle would be an example (although I don't know why anyone would desire to make that particular change unless they absolutely had to). And even in that case an ORM may not be the best decision.

I heard one reference that bothered me that suggested that it is less competent programmers that are against ORM. One could just as easily say that it is programmer incompetent in SQL that are in favor of ORM. So lets not make that type of argument.

Reasons I am against ORM is that I believe it takes away from transparency and makes it difficult to make the inevitable ongoing tweaks that are a major part of all development cycle. If a developer is not fluent in a particular ORM and is hired and needs to make a database change, a task that would othersize take an hour could take many hours. So "rapid" application develop becomes "crippling" application maintenance.

I also believe that complex design patterns where one language automatically writes another language should be generally avoided. ORM isn't the only example of this, of course. Another example is PHP that writes out XHTML. Note every line of code we write needs to be be or should be object oriented. Embedding our markup language and query syntax rather than having our programming language "automagically" do it makes the application more transparent (easier to understand), debug, and maintain. Also, some may say that an ORM "frees" projects from the constraints of a particular database engine. But what about the constraints of your new "fadish" ORM engine? You can pretty much guarantee that the major database engines will be supported longer than most ORMs.

I would also like emphasize that ORM is not VMC, although a lot of VMCs are bundled with ORMs. It is perfectly valid, and I think desirable in most circumstances, to create models that contain hand crafted methods with hand written SQL.

I would also like to dispell one other myth--that ORM are connected to RAD or rapid application development. I do not buy this because in my personal experience I only spend about 10% of my time writing SQL and crafting models for CRUD. So even if ORM cut this time in half (and I don't think it does) then it would only be a 5% increase in my development time (which it isn't). And I'm not an SQL expert or DBA either--just a developer with average SQL skills. SQL is just not a big time sink as long are the DRY principle is followed and models are created with intention.

I personally believe there is a lot of "group think" around ORM--that developers say it should be used because everybody else says it should it be used; it's considered a "hot" technology that one can pad a resume with. Put it on your resume if you feel you must, but but don't use in an important project just because you feel you "should."

  • 1
    +1 for the 5% argument. ORMs (and similar middleware) make it even easier to solve something that was already easy in the first place.
    – user44761
    Feb 3 '13 at 20:33

So, I'm looking for the best or most convincing arguments that you have put forward FOR the use of ORM tools.

There is no way to convince anyone who is against ORM.

You can, however, prove that ORM is better. But you can only do this with a fully-functioning ORM implementation that works, is fast, and much simpler than the equivalent SQL.

Also, you'll have to show how to turn on logging so they can watch the SQL go by.

  1. Pick a project that has a controlled level of complexity. Rewriting an existing but broken application is often the best. The data structure is stable, the use cases are known, and you fabricate a unit test suite for measuring correctness and performance.

  2. Implement that project with a super-clean ORM implementation. Super clean. No hacks. No workarounds. Nothing "funny" or outside the tutorial.

  3. Put it into production.

  4. Do maintenance.

  5. Prove that you did it faster, with fewer errors and can do maintenance quicker because of the ORM. This will take a year or more.

  • 3
    -1, not for your opinion, but for the weak argument. One, you cant 'prove' a subjective 'better', two, your steps are basicly 'fixing a broken app using an ORM tool proves its better'. Could one not then fix a broken app that uses ORM by using hand written SQL, and thus prove direct SQL is better? Or rewrite it in a different laguage and prove the language is better? Or replace a broken, unusable computerized system with a paper-based system, and prove paper is 'better'? Feb 1 '11 at 19:09
  • 3
    6. Explain to people why the extra column one app now needs means all apps need to be redeployed.
    – Phil Lello
    Apr 26 '11 at 1:42

In our company we have this against argument for ORM like:

We want control over our SQL.

I do not know how much of a difference it would make but I have always come across this argument.


I'm against ORM and database abstraction in general because:

  1. It encourages people to put business logic (including access control) in the application (or library) not the database. This is bad, because it means if there's a need to do 1 app in a different language, the logic needs to be consistently re-implemented. It also means all developers need to be trusted with all data.
  2. The ORM models I've seen are really intolerant of changes to database structure. So when a field is added to a table for 1 app, all apps need rebuilding/redeploying at the same time, possibly across multiple development languages and geographic locations. This is a maintenance nightmare.
  • 1
    @Phil: I'm normally against putting business logic in the database (except for special cases): (1) separation of concerns, (2) Dbms don't typically support OO languages. Instead I like a nice business layer implemted as an object model. If you didn't trust your devs with data (1) secure your objects in a separate library with restricted access, and (2) get better devs. Why would you want to do the same app in multiple languages? That sounds like a special requirement, not a reason to be "against... database abstraction in general ".
    – Kramii
    Apr 26 '11 at 3:23
  • @Phil: I'd also be interested in your reaction to the arguments here: programmers.stackexchange.com/questions/6246/…
    – Kramii
    Apr 26 '11 at 3:43
  • @Phil - I have to say I find that argument (point 1) bizarre and the exact opposite of the position most dev teams I know would take. 2 is def a good point, but I wouldn't put that as a sole driver to putting all app logic in the DB.
    – ozz
    Apr 26 '11 at 9:27
  • 3
    "It encourages people to put business logic (including access control) in the application", d'oh, that's where it belongs.
    – vartec
    Apr 26 '11 at 11:21
  • @Krammi That's fine with small teams. If you have hundreds of developers, you're not doing due diligence.
    – Phil Lello
    Apr 26 '11 at 23:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.