3 ms·

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 th

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."

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."