131

If you are motivate to the "pros" of an ORM and why would you use an ORM to management/client, what are those reasons would be?

Try and keep one reason per answer so that we can see which one gets voted up as the best reason.

sajadre
  • 1,141
  • 2
  • 15
  • 30
Simon Munro
  • 5,399
  • 6
  • 33
  • 40
  • 4
    you should make it a wiki if you want a poll – frankodwyer Jan 15 '09 at 22:14
  • 1
    +1 for making it a wiki if you want a poll – cletus Jan 15 '09 at 22:16
  • 21
    What about the con's? – Brian Matthews Jan 15 '09 at 22:24
  • 5
    And no spoon, either. No, really, there is a con: performance. It's much easier to optimize DB queries when you don't have to go through the ORM. (I'm not complaining - having recently switched *to* ORM, I'm mostly happy with it; for general purpose, ORM is the way to go; but keep some way to run queries closer to the metal *iff* you need the performance) – Piskvor left the building Jul 02 '10 at 16:21
  • you just shouldn't. stored procedures can do everything you can do with an ORM. – Uğur Gümüşhan Sep 11 '12 at 13:16
  • 2
    @UğurGümüşhan, IMHO the chief benefit of using an ORM is to make developers more productive, by letting them program in the same language and OO paradigm they use in the rest of their app. Stored procedures can't provide that, when they make the developer code in the RDBMS stored procedure language. So they *can't* do everything an ORM can. – Bill Karwin Feb 17 '13 at 17:08
  • http://mikehadlow.blogspot.com/2012/06/when-should-i-use-orm.html – Andy Oct 26 '16 at 22:46
  • A similar question has recently been discussed on [Hacker News](https://news.ycombinator.com/item?id=16809620) and on [Twitter](https://twitter.com/nikolasburk/status/1028888007770816512) – nburk Aug 15 '18 at 14:46
  • After years of using NHibernate in C# and Doctrine in PHP I'll never, ever let an ORM anywhere near my DBs at all. – Alejandro Apr 02 '19 at 23:26
  • @frankodwyer But sir, how am I supposed to get dat sweet sweet rep if I make it a wiki? I am not a dumbass. – NoName Dec 18 '19 at 01:20

16 Answers16

97

The most important reason to use an ORM is so that you can have a rich, object oriented business model and still be able to store it and write effective queries quickly against a relational database. From my viewpoint, I don't see any real advantages that a good ORM gives you when compared with other generated DAL's other than the advanced types of queries you can write.

One type of query I am thinking of is a polymorphic query. A simple ORM query might select all shapes in your database. You get a collection of shapes back. But each instance is a square, circle or rectangle according to its discriminator.

Another type of query would be one that eagerly fetches an object and one or more related objects or collections in a single database call. e.g. Each shape object is returned with its vertex and side collections populated.

I'm sorry to disagree with so many others here, but I don't think that code generation is a good enough reason by itself to go with an ORM. You can write or find many good DAL templates for code generators that do not have the conceptual or performance overhead that ORM's do.

Or, if you think that you don't need to know how to write good SQL to use an ORM, again, I disagree. It might be true that from the perspective of writing single queries, relying on an ORM is easier. But, with ORM's it is far too easy to create poor performing routines when developers don't understand how their queries work with the ORM and the SQL they translate into.

Having a data layer that works against multiple databases can be a benefit. It's not one that I have had to rely on that often though.

In the end, I have to reiterate that in my experience, if you are not using the more advanced query features of your ORM, there are other options that solve the remaining problems with less learning and fewer CPU cycles.

Oh yeah, some developers do find working with ORM's to be fun so ORM's are also good from the keep-your-developers-happy perspective. =)

Chuck
  • 8,282
  • 2
  • 29
  • 24
  • 4
    Well said. While the original poster did specifically look for "pros" and not "cons", I have seen some HORRIBLE SQL created by not understanding the impacts of HOW you use ORM. To me, the biggest benefit is for simple CRUD transactions which are the majority of your DAL code for transactional systems.I think you are splitting hairs between pure ORM and other generated DAL methods. I think anything that helps you translate between objects and the DB could be considered ORM, it is just a different operational model. – Doug Lampe May 14 '13 at 15:38
  • 1
    @Doug - I think the distinction I was after was that a simple DAL consisted of little more than generated CRUD SQL whereas an ORM contained many more abstractions such as navigation properties, collection persistence, dedicated query languages, caches, etc. - A better way of stating my point in light of your observation might be that while it is true that using more features of an ORM lets you implement faster, it is by no means acceptable to remain ignorant of how those features work. Perhaps because the abstractions of ORMs leak more than most.(http://en.wikipedia.org/wiki/Leaky_abstraction) – Chuck May 14 '13 at 17:21
  • 1
    please elaborate on this some more: " if you are not using the more advanced query features of your ORM, there are other options that solve the remaining problems". also, as creator of hibernate gavin king says: "Indeed, systems like Hibernate are intentionally designed as "leaky abstractions" so that it's possible to easily mix in native SQL where necessary. The leakiness of the ORM abstraction is a feature, not a bug!" -- https://www.reddit.com/r/programming/comments/2cnw8x/what_orms_have_taught_me_just_learn_sql/ – jungle_mole Aug 18 '16 at 20:43
  • 1) This is old. Back then, ORMs had all features (caches, queries, batching, etc). IMHO, object based, polymorphic queries were the only ORM feature that code gen (explicit ADO mapping) could not easily provide. 2) While some useful holes were intentionally left, there were also necessary evils & advanced features that created a high learning curve in ORMs. So, my answer was to use code gen instead of ORMs unless you needed advanced queries. *) Present time, there is enough variety in ORMs that the right feature set for your team is probably out there. My team is fond of Linq2DB now. – Chuck Aug 19 '16 at 22:20
63

Speeding development. For example, eliminating repetitive code like mapping query result fields to object members and vice-versa.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • 4
    Repetitive code is very bad, but could you not build an abstraction that would remove this? For example, you can have a table / query results object that will give you back rows that you can then do stuff with. ORMs seem to break rows in to individual class instances, rather than going in at the DB's chosen abstraction, which is tables / rows of query results. I'm not saying that this means ORMs aren't good, but I'm not sure this alone is a reason for using them. – Benjohn Nov 10 '14 at 21:48
  • @Benjohn, I agree that the ORM solution treats individual rows as objects, whereas RDBMS treats *sets* of rows as an entity. There are things you can do in the RDBMS mindset that you can't do in an OO mindset. – Bill Karwin Nov 11 '14 at 15:12
  • This is like buying a whole car just to use the trunk, there are many ways to avoid repetitive work – mohas Oct 06 '18 at 15:49
60

Making data access more abstract and portable. ORM implementation classes know how to write vendor-specific SQL, so you don't have to.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • 68
    While I agree that this is a feature of ORM's, I'd propose that the use-case is fairly limited. I have never really used anything but MySql and sqlite for about a decade. I think it's probably a very rare requirement for most developers. – troelskn Dec 29 '09 at 12:44
  • 44
    @troelskn: I agree, I have used many RDBMS products, but never more than one or two per project. So portability isn't the most practical value of abstracting SQL. I think many ORM users simply want to avoid coding in SQL at all. – Bill Karwin Dec 29 '09 at 19:00
  • 2
    vendors come out with new versions/features all the time...just need some cool people to write the dialect and easy upgrade it is! – dotjoe Mar 12 '10 at 01:38
  • 5
    Typical useless answer I wonder why it is marked as good answer seems like the guy who asks the question just try to justify to his boss that he should use an ORM :) My question would rather be what kind of problem you'll encounter with Hibernate http://stackoverflow.com/questions/6477170/why-im-scared-to-use-hibernate – user310291 Jun 25 '11 at 10:24
  • 2
    @user310291: The OP did not ask for problems or pitfalls, he asked for benefits of using an ORM. Of course there are pros and cons, but he asked for the pros. Frankly, I'm surprised that this answer got accepted and got as many upvotes as it did, because I wouldn't count it as the chief benefit of an ORM. – Bill Karwin Jun 25 '11 at 17:08
  • 1
    ORM to SQL is like jQuery to JS. Convenient, but you're not getting the whole picture and relying on others to hopefully do it right. – DanMan Apr 12 '14 at 13:33
14

Supporting OO encapsulation of business rules in your data access layer. You can write (and debug) business rules in your application language of preference, instead of clunky trigger and stored procedure languages.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • 1
    Don't you want to have your business rules in the database though? That's a benefits of a database, right: multiple clients can use the same interface provided by the DBMS. If lots of your interface logic is locked up in a particular client's ORM code, it isn't in the database and other clients aren't using it. Cue front office back office breaks (one clients model getting out of line with another's). – Benjohn Nov 10 '14 at 21:55
  • 1
    @Benjohn, I tend to put simply business rules into the database, but more complex rules are not easily formed in declarative constraints. E.g. "customer gets 10% off entire order the first time they buy more than three pairs of slacks from the same brand." How would you put that business rule into the database (keep in mind an answer involving stored procedures is clunky). – Bill Karwin Nov 11 '14 at 15:10
  • It's 2020, I don't see anyone using stored procedures any more. So does you point still stands? – ospider Aug 02 '20 at 07:02
  • I think my point is that people _don't_ use stored procedures, they use application code. Did you understand something different? – Bill Karwin Aug 02 '20 at 18:55
12

Generating boilerplate code for basic CRUD operations. Some ORM frameworks can inspect database metadata directly, read metadata mapping files, or use declarative class properties.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
9

You can move to different database software easily because you are developing to an abstraction.

Matt Fenelon
  • 144
  • 1
  • 7
  • 64
    In 30 plus years of doing datbase work, I have not once had to do this. – HLGEM Feb 01 '10 at 19:16
  • 7
    Doesn't mean it's not possible! :) – Matt Fenelon Feb 15 '10 at 10:18
  • 4
    @HLGEM it means you're closing the choices for the client. It could actually happen, in only 3 years of webapps work, we've built portable software using ORMs – Alfabravo Feb 20 '10 at 17:36
  • 2
    You may find it useful in case you want to run tests on an in memory database – Carlos Parraga Aug 30 '18 at 18:19
  • 2
    It's possible that several instances of the same software might use different databases. But actually moving existing data from one DB software to another really rarely happen. And when it does, many ORMs don't actually assist you with that. – jlh Nov 15 '18 at 10:15
  • We had a case where we replaced the RDBMS without changing one single line of code. Also we use two different RDMBS with the same code - one for production, other for testing. For example the application runs with MySQL in production, but the functional tests are run against sqlite3 on the local machine of each developer. – cezar Oct 17 '21 at 07:10
  • Just because you haven't had to do this, doesn't mean others haven't. Do you really think an app that is growing quickly can live forever on Heroku Postgres? – Aaron Nov 20 '21 at 02:45
5

Development happiness, IMO. ORM abstracts away a lot of the bare-metal stuff you have to do in SQL. It keeps your code base simple: fewer source files to manage and schema changes don't require hours of upkeep.

I'm currently using an ORM and it has sped up my development.

curiousdork
  • 1,034
  • 2
  • 12
  • 13
4

So that your object model and persistence model match.

cletus
  • 616,129
  • 168
  • 910
  • 942
3

To minimise duplication of simple SQL queries.

Tim Wardle
  • 1,723
  • 1
  • 14
  • 14
3

The reason I'm looking into it is to avoid the generated code from VS2005's DAL tools (schema mapping, TableAdapters).

The DAL/BLL i created over a year ago was working fine (for what I had built it for) until someone else started using it to take advantage of some of the generated functions (which I had no idea were there)

It looks like it will provide a much more intuitive and cleaner solution than the DAL/BLL solution from http://wwww.asp.net

I was thinking about created my own SQL Command C# DAL code generator, but the ORM looks like a more elegant solution

Dan McClain
  • 11,780
  • 9
  • 47
  • 67
2

Abstract the sql away 95% of the time so not everyone on the team needs to know how to write super efficient database specific queries.

Jared
  • 39,513
  • 29
  • 110
  • 145
2

I think there are a lot of good points here (portability, ease of development/maintenance, focus on OO business modeling etc), but when trying to convince your client or management, it all boils down to how much money you will save by using an ORM.

Do some estimations for typical tasks (or even larger projects that might be coming up) and you'll (hopefully!) get a few arguments for switching that are hard to ignore.

Anders Fjeldstad
  • 10,724
  • 2
  • 33
  • 50
  • One of the best answers. I mean the part in bold. Many developers forget that they have to charge the customer. After all we work for money. – cezar Oct 17 '21 at 07:19
2

Compilation and testing of queries.

As the tooling for ORM's improves, it is easier to determine the correctness of your queries faster through compile time errors and tests.

Compiling your queries helps helps developers find errors faster. Right? Right. This compilation is made possible because developers are now writing queries in code using their business objects or models instead of just strings of SQL or SQL like statements.

If using the correct data access patterns in .NET it is easy to unit test your query logic against in memory collections. This speeds the execution of your tests because you don't need to access the database, set up data in the database or even spin up a full blown data context.[EDIT]This isn't as true as I thought it was as unit testing in memory can present difficult challenges to overcome. But I still find these integration tests easier to write than in previous years.[/EDIT]

This is definitely more relevant today than a few years ago when the question was asked, but that may only be the case for Visual Studio and Entity Framework where my experience lies. Plugin your own environment if possible.

Community
  • 1
  • 1
Chuck
  • 8,282
  • 2
  • 29
  • 24
0

I think one cons is that ORM will need some updation in your POJO. mainly related to schema, relation and query. so scenario where you are not suppose to make changes in model objects, might be because it is shared among more that on project or b/w client and server. so in such cases you will need to split it in two levels, which will require additional efforts .

i am an android developer and as you know mobile apps are usually not huge in size, so this additional effort to segregate pure-model and orm-affected-model does not seems worth full.

i understand that question is generic one. but mobile apps are also come inside generic umbrella.

Shailendra Singh Rajawat
  • 8,172
  • 3
  • 35
  • 40
0

.net tiers using code smith templates

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

Why code something that can be generated just as well.

Jobo
  • 940
  • 6
  • 11
  • Ugh. We used Net Tiers on a big commercial project, and I would highly advise against using it. The problem is that it is not composable. Want to query Foo and Bar objects? You can't write joins, you have to issue separate queries for each object type you want. This results in lots of calls to the database, which can break performance and atomicity. Bad, bad, bad. Stay away. – Judah Gabriel Himango Apr 05 '11 at 17:23
0

convince them how much time / money you will save when changes come in and you don't have to rewrite your SQL since the ORM tool will do that for you

zmf
  • 9,095
  • 2
  • 26
  • 28