There are a whole lot of strong opinions about ORM floating around the internet and elsewhere. When you see so manypassionate, conflicting opinions in so many different threads, it’s a pretty clear sign you’re looking at a religious argument rather than a rational debate. And, as in any good religious argument — big endian or little endian, butter side up or butter side down, vi or emacs, Team Jacob or Team Edward — this one has two sides, too.
The Two Sides of the ORM Debate
The ORM debate isn’t about technology; it’s about values. People tell you that you should or shouldn’t use ORM based on what they think matters more: clean data access, or clean code.
The first camp — call them the “modelers” — thinks that software should concentrate on the model level and treat the data store as incidental. People in this camp say you should use ORM because it lets you describe at a high level how your program’s data should be stored and retrieved from the database with little code using the language of the program without making the model “leak” SQL (or other data language du jour).
The second camp — call them the “persisters” — thinks that software should concentrate on the persistence level and treat the code as incidental. People in this camp don’t use ORM because they think the program should be written so its data storage and access patterns fit naturally with the underlying data store, and all data access is controlled and explicit.
So Who’s Right?
Oh, yeah. It’s totally as simple as right and wrong.
No one is right, and no one is wrong. Both camps have good points and bad points, and both approaches can lead to good and bad code. But in the debate, most people choose a side based personal preferences and values rather than evidence. The emperor isn’t wearing any clothes here.
Now, this would be a shitty programming post if I didn’t tell you what to do as if I had all the answers. (How else am I supposed to make myself sound smart?) So here are some best practices from both camps:
- If you’re going to use ORM, you should make your model objects as simple as possible. Be more vigilant about simplicity than normal to make sure your model objects really are just Plain ol’ Data. Otherwise you may end up wrestling with your ORM to make sure the persistence works like you expect it to, and it’s not looking for methods and properties that aren’t actually there.
- If you’re not going to use ORM, you should probably define DAOs or persistence and query methods to avoid coupling the model layer with the persistence layer. Otherwise you end up with SQL in your model objects and a forced dependency on your project.
- If you know your data access patterns are generally going to be simple (like basic object retrieval) but you don’t know all of them up front, you should think about using an ORM. While ORMs can make building complex queries confusing to build and difficult to debug, an ORM can save you huge amounts of time if your queries are generally pretty simple (Point, modelers.)
- If you know your data access pattern is going to be complex or you plan to use a lot of database-specific features (like PostgreSQL window functions), you may not want to use an ORM. While many ORMs (like Hibernate) let you access the underlying data source connection pretty easily , if you know you’re going to have to throw around a lot of custom SQL, you may not get a lot of value out of ORM to begin with because you’re constantly going to have to break out of it. (Point, persisters.)
- If it absolutely, positively, has to, has to, has to go fast, you may not want to use ORM. The only way to be absolutely sure all your queries consistently go fast is to plan your database structure carefully, manage your data access pattern with extreme prejudice, commit to one data store, and write your own queries optimized against that data store. (Point, persisters.) That having been said, most software really doesn’t have to go truly fast; it just has to go fast enough. (Point, modelers.)
On Persistence Atheism
ORM isn’t about religion; neither is deciding whether to use it. ORM isn’t God, or the Devil. Neither the modelers nor the persisters win the argument on theory or practice. Religion is irrelevant, and so is the debate itself. You should be getting work done, not arguing over which way to get work done is better. SPOILER: They both work.
Whether or not you should use ORM isn’t about other people’s values, or even your own. It’s about choosing the right technique for your application based on its technical requirements.
“To ORM, or not to ORM?” It doesn’t matter. I don’t care, and neither should anybody else. Stop asking, and stop telling. Use ORMor don’t based not on personal values but on what your app needs more: control over data access, or less code to maintain. If you decide to use ORM, find one you like and use it. Done.
Now that you know everything there is to know about ORM (you’re welcome), feel free to make your own choice. And for goodness’ sake, stop whining about it online. STFU and GBTW.
And emacs is totally better.