Why use an ORM?
blog.langoor.mobi
Why use an ORM?
1–10 of 13 posts
Re: Why use an ORM?
#2There are two sides of the argument and both have valid arguments. An ORM abstracts a lot of complexity when it comes to mapping tables, joins and sub-queries so if you don't understand the underlying SQL queries your ORM is performing and something breaks, you're at the mercy of the ORM to provide you with adequate error messages and means for debugging. The way of looking at an ORM is it is a framework for your database much like jQuery is a framework for Javascript and Rails is a framework for Ruby. You can get by using the framework but run the risk of not understanding the underlying structure and you're screwed if the framework you're using (or ORM) is no longer updated or works with your particular version of MySQL or whatever.
Having said that, if you're using an established ORM like Doctrine then the possibility of ever needing to understand the underlying database structure and complexities is almost null. The time saving benefits, pooling, support for transactions, security best practices for your queries and caching features alone make an ORM worthwhile in the end. I think ORM's are great if you dig deeper and explore how the ORM works, it doesn't mean you have to write straight-up queries, but it pays in-case you are ever in a situation where an ORM isn't allowed by a manager or senior developer and you're asked to write a native query.
Re: Why use an ORM?
#3There are two sides of the argument and both have valid arguments. An ORM abstracts a lot of complexity when it comes to mapping tables, joins and sub-queries so if you don't understand the underlying SQL queries your ORM is performing and something breaks, you're at the mercy of the ORM to provide you with adequate error messages and means for debugging. The way of looking at an ORM is it is a framework for your dat…
I've completely left ORM-land (in PHP). I find that:
* I have little need to switch databases
* ORMs provide little support for things like
views, stored procedures, custom types
* I like to see the SQL in context of my code.
Re: Why use an ORM?
#4There are two sides of the argument and both have valid arguments. An ORM abstracts a lot of complexity when it comes to mapping tables, joins and sub-queries so if you don't understand the underlying SQL queries your ORM is performing and something breaks, you're at the mercy of the ORM to provide you with adequate error messages and means for debugging. The way of looking at an ORM is it is a framework for your dat…
I've completely left ORM-land (in PHP). I find that: * I have little need to switch databases * ORMs provide little support for things like views, stored procedures, custom types * I like to see the SQL in context of my code. I've come to these conclusions for myself after having run the gauntlet of several Symfony projects. There was simply too much abstraction from the actual code that "did the work." I found mysel…
Same here. In my opinion ORM's are evil. They are very easy to get started with but once your application logic becomes more complex you will find that you've painted yourself in a corner. I'm all for an DB abstraction but I stay away from ORM's.
Re: Why use an ORM?
#5My company has a very large application that still utilizes an ORM (Doctrine).
The primary benefit is the lazy (proxy) loading of entities and mapping data onto complex graphs, not to mention updates that span multiple entities in a single transaction.
Performance-wise, we've reduced lazy loading via eager selects, result caches, and one instance of mapping SQl results back to an object.
All in all, it feels better working with objects than it does with raw data, and it is very reliable in my experience.
Re: Why use an ORM?
#6My company has a very large application that still utilizes an ORM (Doctrine). The primary benefit is the lazy (proxy) loading of entities and mapping data onto complex graphs, not to mention updates that span multiple entities in a single transaction. Performance-wise, we've reduced lazy loading via eager selects, result caches, and one instance of mapping SQl results back to an object. All in all, it feels better w…
this is the trouble with ORM's though - mapping things into complex graphs is anti-relational. SQL wants you to work in sets. ORM's are trying to bridge that impedance mismatch - but the real answer is to not fight it.
Re: Why use an ORM?
#7Maybe I'm misunderstanding, but these seem like terrible reasons to use an ORM and good reasons for learning how to use a database. The purpose of the ORM is to provide a more convenient way of getting stuff done, not "cover up details so I don't have to understand them."
Re: Why use an ORM?
#8There are two sides of the argument and both have valid arguments. An ORM abstracts a lot of complexity when it comes to mapping tables, joins and sub-queries so if you don't understand the underlying SQL queries your ORM is performing and something breaks, you're at the mercy of the ORM to provide you with adequate error messages and means for debugging. The way of looking at an ORM is it is a framework for your dat…
I've completely left ORM-land (in PHP). I find that: * I have little need to switch databases * ORMs provide little support for things like views, stored procedures, custom types * I like to see the SQL in context of my code. I've come to these conclusions for myself after having run the gauntlet of several Symfony projects. There was simply too much abstraction from the actual code that "did the work." I found mysel…
I too have left ORM-land (in C#). I found that the first two of your points are absolutely true. I've also found that if you know how to code a clean, well-factored data access layer then it doesn't necessarily even take a whole lot longer than wiring up an ORM does for non-trivial cases.
I also found that using the ORM was having a detrimental impact on performance and scalability in a subtle way that had nothing to do with the ORM itself: It's that I got used to operating so far from the database layer that I wasn't really aware of what was going on down there. Last time I did a conversion of a project away from ORM, the number of forehead-slapping moments when I noticed a simple way to improve an operation's performance by at least one order of magnitude was downright embarrassing.
That said, that's where I depart on the third point. I've also moved to using stored procedures for everything. I don't know if the situation is quite the same for MySQL users, but in Microsoft-land the amount of tooling SQL Server and SQL Server Management Studio provide to help with managing, analyzing, and refactoring SQL code is really pretty impressive. . . and if you divorce your SQL code from its native environment by demoting it to being nothing more than string resources that are subservient to the application code, you're letting go of a lot of those tools. Or at the very least, creating a lot of unnecessary friction when it comes to getting at them.
However, as a RAD kit I think ORMs are fantastic. They can, as the article highlights, do a lot to protect someone with limited skills in database work from getting themselves into trouble. But they're still just a RAD kit, and like any RAD kit they have their limitations.
Re: Why use an ORM?
#9My company has a very large application that still utilizes an ORM (Doctrine). The primary benefit is the lazy (proxy) loading of entities and mapping data onto complex graphs, not to mention updates that span multiple entities in a single transaction. Performance-wise, we've reduced lazy loading via eager selects, result caches, and one instance of mapping SQl results back to an object. All in all, it feels better w…
this is the trouble with ORM's though - mapping things into complex graphs is anti-relational. SQL wants you to work in sets. ORM's are trying to bridge that impedance mismatch - but the real answer is to not fight it.
I still don't see how this is the "trouble with ORMs". I haven't had any trouble with this, and we have a highly-relational, yet complex graph structure.
As a tool, it seems to work extremely well, despite academic objections to it.
Re: Why use an ORM?
#10Earlier quoted context omitted.
I've completely left ORM-land (in PHP). I find that: * I have little need to switch databases * ORMs provide little support for things like views, stored procedures, custom types * I like to see the SQL in context of my code. I've come to these conclusions for myself after having run the gauntlet of several Symfony projects. There was simply too much abstraction from the actual code that "did the work." I found mysel…
I too have left ORM-land (in C#). I found that the first two of your points are absolutely true. I've also found that if you know how to code a clean, well-factored data access layer then it doesn't necessarily even take a whole lot longer than wiring up an ORM does for non-trivial cases. I also found that using the ORM was having a detrimental impact on performance and scalability in a subtle way that had nothing to…
Can you expand on your preference to put everything into stored procedures? I'm increasingly curious about this because I find I'm writing more procedures in postgresql. Or perhaps you can refer to a book/link?
And this is the third time this week I've had someone laud the benefits of SQL Server dev tools.
Thanks.