4 ms·

I'm not really a web guy, so perhaps I was never the target audience for ORMs. I was surprised by the author's assertion that they seem simple and elegant at f

I'm not really a web guy, so perhaps I was never the target audience for ORMs. I was surprised by the author's assertion that they seem simple and elegant at first -- maybe it's because I learned SQL first. My first impression of ORMs was, "this looks impossible to do right, in general, and basically untrustworthy. If it's going to work at all, you have to impose harsh limitations on both the 'object' side and the 'relational' side." Having read the article, I'm feeling pretty self-congratulatory. Other than claims to "elegance", what was the motivation for ORMs?

code_pig 10y ago
ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone. That's the sales pitch. In essence, they are rarely ever a good idea. As database drivers have become more simple to manage, and ORM's have tried to become more complex, the value proposition (which I'm loath to suggest existed in the first place) dissipated without any trace.
- 0x445442 10y ago
  Yeah, SQL mapping frameworks, like MyBatis, seem to be the pragmatic sweet spot for most use cases.
  - zzzeek 10y ago
    Wikipedia: > MyBatis is a Java persistence framework that couples objects with stored procedures or SQL statements using an XML descriptor or annotations IOW an ORM.
- wdewind 10y ago
  > In essence, they are rarely ever a good idea. I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM. Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to. If your models map 1:1 to database tables it's hard to see why you wouldn't want an ORM, and I think there are a lot of great arguments for structuring your data like that (and of course some against it as well).
  - dhd415 10y ago
    >>I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM.<< Whether you use an ORM or not, your data layer can (and generally should) be designed to present a logical data model that may differ from your physical model. While some ORMs offer easy hooks for the addition of caching and analytics, the same is true for a well-designed data layer. I've also seen naive ORM implementations of those kinds of features cause more trouble than they were worth. >>Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to.<< While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot.
    - gnaritas 10y ago
      > While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot. No, lack of thought in using the tools isn't the same as the tool forcing you to do it. Put the complex and efficient query into a view and map the view with the ORM, problem solved and SQL used appropriately and the ORM used appropriately.
    - wdewind 10y ago
      You completely disregarded all of the organizational and communicative benefits I mentioned in favor of performance. Sometimes that will be the right choice to make, sometimes (I'd argue frequently) it will not. > A highly performant data layer is going to interact with the database in ways that ORMs generally cannot. This is not true, unless using the data layer instead of ORM allows you to structure your data differently. In which case, sure.
- zzzeek 10y ago
  If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM.
  - NoGravitas 10y ago
    As bgribble said above about Greenspun's Law as applied to ORMs.
- gnaritas 10y ago
  > ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone. Not remotely correct; the purpose of an ORM is to map result sets into objects to avoid repetitive hand coding of those mappings for programs that work with objects. It isn't' about a dev's comfort zone, it's about eliminating the need to hand write repetitive mapping code. > In essence, they are rarely ever a good idea. As Also wrong, they are nearly always a good idea as they drastically improve productivity by eliminating tons of manual code that simply isn't necessary to write. You don't seem to understand the value proposition of an ORM enough to be able to critique it.
  - bitcrusher 10y ago
    And so the debate rages on... There are two sides to this, illustrated by the parent post and you post. Ultimately, it comes down to style preference and his little actual tangible TECHNICAL benefit. The benefits to team process/organization can definitely be argued for ( or even against ) but, that is why the debate will rage on for eternity, IMO.
    - gnaritas 10y ago
      If there were no tangible technical benefit ORM's wouldn't be popular. The debate rages on because ORM haters like Climate Change deniers, rarely understand that which they critique. The debate exists because one side is ignorant and cant' tell the difference between using a tool in the wrong situation and a bad tool. ORM's are a great and useful tool and drastically reduce hand written and duplicated code; period, this is a fact and is not debatable. That in some cases they can be misapplied and cause problems doesn't make the tool bad, but it does feed anecdotes that ORM deniers like to pretend is all that exist.
    - runin2k1 10y ago
      The debate is stupid because one side is taking an absolute position against a programming tool that has been used successfully by thousands(millions?) of projects. The funny thing about the anti-ORM-ists position is that they are either: 1) Exclusively embedding raw SQL in their code, and accessing each query result by also hard-coding column names and value types in map look-ups. Maybe this is a "pure" approach, but it is also very brittle as models evolve. Or, 2) They develop their own naive ORM implementation without the self-awareness to realize that is what they are doing. As zzzeek said, "If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM."
snomad 10y ago
One motivation, especially with a code-first work flow, is tying source control and db versioning together. With Entity Framework, you can downgrade the DB structure back to a specific point in time.
- dhd415 10y ago
  Versioning a database schema is orthogonal to the use of an ORM even though EF is an ORM that also facilitates database schema versioning.
bgribble 10y ago
I'm the last person to want to really defend ORMs. But there's a flavor of Greenspun's Tenth Rule [1] that applies... it would go something like "Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." A decent ORM can help manage the impedance mismatch between SQL and the app language. ORMs are very leaky abstractions and definitely restrict design, but metaprogramming SQL in an app language has its own drawbacks. [1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
- aeorgnoieang 10y ago
  This has been my experience as well. Being very comfortable with SQL, I initially thought very poorly of ORMs, especially given that my first major exposure was to a "buggy" half-hand-baked implementation. But, like a lot of other things, they definitely exist for a reason and can often be the best option given the particular tradeoffs you're given.
- Terr_ 10y ago
  That's my experience with a certain 10+ year old piece of PHP enterprise software. Not only is the ORM homegrown, but it started as a data-mapper and somehow ended up being used in a degenerate way like active-record, and has lot of "fun" quirks.
- lowbloodsugar 10y ago
  >"Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." Inherited a product that used an ORM. The application was a java application running on multiple hosts and non-sticky sessions. It used session caching, which round-robin load balancing broke silently. Hah, no I'm kidding! It used global caching! Then it was replete with transaction annotations, but it was the wrong transactional level and the transactional annotations were not configured to be used anyway. Then the schema was hard-coded (which I'd usually say is a good thing) because they'd had the database fall over when the ORM attempted to update the schema. Of course the hard-coded schema was missing things and only fixed when the, now manual, updates to the DB caused the queries to outright fail. While the ORM prevented SQL injection, the belief that the ORM somehow handled any kind of injections, meant that the outputs weren't sanitized and XSS injections were not handled at all. So perhaps the problem isn't SQL or ORMs, its that some programmers don't know what the fuck they are doing, and ORMs make it easier to postpone that enlightenment, sometimes indefinitely.
scarface74 10y ago
Coming from c# and using Linq: 1. Type safety instead of magic strings 2. Composibiity of queries. 3. Testability - I can mock out the dbcontext in unit test and use an in memory List<T> to test queries without having a database dependencies. But these days, for any new project, my default is to avoid relational databases unless there is good reason for them. Even for BI, my live database is more than likely going to be NoSql and use a combination of CQRS, Event Sourcing, and messaging.

code_pig 10y ago

ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone. That's the sales pitch. In essence, they are rarely ever a good idea. As database drivers have become more simple to manage, and ORM's have tried to become more complex, the value proposition (which I'm loath to suggest existed in the first place) dissipated without any trace.

0x445442 10y ago
Yeah, SQL mapping frameworks, like MyBatis, seem to be the pragmatic sweet spot for most use cases.
- zzzeek 10y ago
  Wikipedia: > MyBatis is a Java persistence framework that couples objects with stored procedures or SQL statements using an XML descriptor or annotations IOW an ORM.
wdewind 10y ago
> In essence, they are rarely ever a good idea. I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM. Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to. If your models map 1:1 to database tables it's hard to see why you wouldn't want an ORM, and I think there are a lot of great arguments for structuring your data like that (and of course some against it as well).
- dhd415 10y ago
  >>I'm not sure I agree with this. There is a massive benefit to having not just your entire engineering org thinking in an object oriented fashion, but also your entire product org. Designers and PMs having a deep understanding of the data model is extremely useful, and to the extent that everyone is already speaking in OO terms (ie: your records are already going to be structured in this fashion), an ORM makes a ton of sense. Not only does it give you abstracted and simplified syntax for common access patterns, it gives you a shim to add in all kinds of stuff like caching, analytics etc., that would be extremely difficult without an ORM.<< Whether you use an ORM or not, your data layer can (and generally should) be designed to present a logical data model that may differ from your physical model. While some ORMs offer easy hooks for the addition of caching and analytics, the same is true for a well-designed data layer. I've also seen naive ORM implementations of those kinds of features cause more trouble than they were worth. >>Of course there are pitfalls, mostly poorly constructed queries that don't perform well, but any ORM will let you write raw SQL when you need to.<< While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot.
  - gnaritas 10y ago
    > While this is technically true, many ORMs force you into database access patterns such a multiple synchronous roundtrips to the database that do not perform well and cannot be resolved simply by dropping to raw SQL. A highly performant data layer is going to interact with the database in ways that ORMs generally cannot. No, lack of thought in using the tools isn't the same as the tool forcing you to do it. Put the complex and efficient query into a view and map the view with the ORM, problem solved and SQL used appropriately and the ORM used appropriately.
  - wdewind 10y ago
    You completely disregarded all of the organizational and communicative benefits I mentioned in favor of performance. Sometimes that will be the right choice to make, sometimes (I'd argue frequently) it will not. > A highly performant data layer is going to interact with the database in ways that ORMs generally cannot. This is not true, unless using the data layer instead of ORM allows you to structure your data differently. In which case, sure.
zzzeek 10y ago
If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM.
- NoGravitas 10y ago
  As bgribble said above about Greenspun's Law as applied to ORMs.
gnaritas 10y ago
> ORMs are essentially abstracting relational data structures to fit an OOP development style. It allows OOP engineers to access a DB without straying far from their comfort zone. Not remotely correct; the purpose of an ORM is to map result sets into objects to avoid repetitive hand coding of those mappings for programs that work with objects. It isn't' about a dev's comfort zone, it's about eliminating the need to hand write repetitive mapping code. > In essence, they are rarely ever a good idea. As Also wrong, they are nearly always a good idea as they drastically improve productivity by eliminating tons of manual code that simply isn't necessary to write. You don't seem to understand the value proposition of an ORM enough to be able to critique it.
- bitcrusher 10y ago
  And so the debate rages on... There are two sides to this, illustrated by the parent post and you post. Ultimately, it comes down to style preference and his little actual tangible TECHNICAL benefit. The benefits to team process/organization can definitely be argued for ( or even against ) but, that is why the debate will rage on for eternity, IMO.
  - gnaritas 10y ago
    If there were no tangible technical benefit ORM's wouldn't be popular. The debate rages on because ORM haters like Climate Change deniers, rarely understand that which they critique. The debate exists because one side is ignorant and cant' tell the difference between using a tool in the wrong situation and a bad tool. ORM's are a great and useful tool and drastically reduce hand written and duplicated code; period, this is a fact and is not debatable. That in some cases they can be misapplied and cause problems doesn't make the tool bad, but it does feed anecdotes that ORM deniers like to pretend is all that exist.
  - runin2k1 10y ago
    The debate is stupid because one side is taking an absolute position against a programming tool that has been used successfully by thousands(millions?) of projects. The funny thing about the anti-ORM-ists position is that they are either: 1) Exclusively embedding raw SQL in their code, and accessing each query result by also hard-coding column names and value types in map look-ups. Maybe this is a "pure" approach, but it is also very brittle as models evolve. Or, 2) They develop their own naive ORM implementation without the self-awareness to realize that is what they are doing. As zzzeek said, "If your application has objects, and talks to a relational database to marshal result rows into instances of those objects, you are using an ORM."

snomad 10y ago

One motivation, especially with a code-first work flow, is tying source control and db versioning together. With Entity Framework, you can downgrade the DB structure back to a specific point in time.

dhd415 10y ago
Versioning a database schema is orthogonal to the use of an ORM even though EF is an ORM that also facilitates database schema versioning.

bgribble 10y ago

I'm the last person to want to really defend ORMs. But there's a flavor of Greenspun's Tenth Rule [1] that applies... it would go something like "Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." A decent ORM can help manage the impedance mismatch between SQL and the app language. ORMs are very leaky abstractions and definitely restrict design, but metaprogramming SQL in an app language has its own drawbacks. [1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

aeorgnoieang 10y ago
This has been my experience as well. Being very comfortable with SQL, I initially thought very poorly of ORMs, especially given that my first major exposure was to a "buggy" half-hand-baked implementation. But, like a lot of other things, they definitely exist for a reason and can often be the best option given the particular tradeoffs you're given.
Terr_ 10y ago
That's my experience with a certain 10+ year old piece of PHP enterprise software. Not only is the ORM homegrown, but it started as a data-mapper and somehow ended up being used in a degenerate way like active-record, and has lot of "fun" quirks.
lowbloodsugar 10y ago
>"Any sufficiently complicated database-using app has a buggy implementation of half an ORM with major cache-consistency problems, some broken/outdated assumptions about the schema, and a few SQL injection holes you could drive a truck through." Inherited a product that used an ORM. The application was a java application running on multiple hosts and non-sticky sessions. It used session caching, which round-robin load balancing broke silently. Hah, no I'm kidding! It used global caching! Then it was replete with transaction annotations, but it was the wrong transactional level and the transactional annotations were not configured to be used anyway. Then the schema was hard-coded (which I'd usually say is a good thing) because they'd had the database fall over when the ORM attempted to update the schema. Of course the hard-coded schema was missing things and only fixed when the, now manual, updates to the DB caused the queries to outright fail. While the ORM prevented SQL injection, the belief that the ORM somehow handled any kind of injections, meant that the outputs weren't sanitized and XSS injections were not handled at all. So perhaps the problem isn't SQL or ORMs, its that some programmers don't know what the fuck they are doing, and ORMs make it easier to postpone that enlightenment, sometimes indefinitely.

scarface74 10y ago

Coming from c# and using Linq: 1. Type safety instead of magic strings 2. Composibiity of queries. 3. Testability - I can mock out the dbcontext in unit test and use an in memory List<T> to test queries without having a database dependencies. But these days, for any new project, my default is to avoid relational databases unless there is good reason for them. Even for BI, my live database is more than likely going to be NoSql and use a combination of CQRS, Event Sourcing, and messaging.