Choosing an ORM strategy | Hacker News Reader

Choosing an ORM strategy

lostechies.com

20 pointsfogus9 comments

I feel the notion of "ORM strategy" is fundamentally broken. The idea of an ORM is to allow your object model to match the program, and your data model to match your DB/data/etc. An ORM strategy feels like point missing, it is a tool to allow interaction with data, not the data model itself.

The article is essentially telling you to choose one of these pre-written notions of how a programs data flow operates.

If you go ahead and create your own dataflow notion, you'll have to adjust your ORM to fit, so its better to pick one and go with it.

I have a brilliant ORM strategy: don't.

To the folks putting down ORMs: what is your alternative to solve the same problems? (A positive note would be nice.) For my work, using something with a Data Mapper strategy has been useful.

just use hash maps: http://www.youtube.com/watch?v=rI8tNMsozo0

An ORM at the basic level just populates some data structure (could be a hash map) from your database.

At some point when an app gets complex programmers tend to keep SQL organized so it's not all throughout the code, just like keeping view logic separate. To me that is just a simple ORM as well.

There seems to be an anti-ORM trend but I suspect it's more of an opposition to certain established ORMs that are really complicated to work with.

If that's not true, I'm also curious to hear about other strategies that people are using these days. Having no strategy at all seems a little sloppy to me, but I'm always open to new ideas.

ORMs either arise from need (homegrown) or are bought with way more features than you need and the associated complexity that brings.

If there were a way to scale an ORM so it can modularly add features/complexity as you need it (ie, customize the metamodel complexity), that would be the most ideal approach.

On the other hand, testing thousands to millions of possible use cases in combined codebases is a nightmare.

I agree. I've written many home-grown ORMs as well as used a few well-known ones. It's definitely easier in some ways writing your own because you understand all of the details & it has nothing in it that is unneeded. The downside is that you don't have the community support maintaining the code and providing support resources. On the flip-side I've spent days researching and tweaking hibernate mapping files, occasionally making me want to throw my laptop out the window!

One thing is for sure, no matter what ORM or similar solution you use, if you don't know how to observe and understand the SQL that is generated then you won't be able to use it efficiently.

In my case, we had a need to keep the datatypes and queries tightly coupled to their specific use cases, largely for the sake of performance. So we were using a strategy along the lines of what's described in the "result-set-based relational mapping" section of the article. But over time it started to feel like the data access layer was turning into one big example of the softcoding anti-pattern.

So the code's been going back toward just writing the routines for dumping results into objects in application code, and we're finding that this does seem to be more maintainable. And it's definitely proving easier to reason about bits and cycles without this big (trying-to-be) black box right smack dab in the middle of everything. Not to mention that having to think in 3 languages is more than 50% harder than having to think in two.

ETA: I'm beginning to think that last bit defines the difference between ORM success and ORM frustration. If your needs are such that can largely avoid the SQL, then you can largely stick to just reasoning in the application's programming language and the ORM's data mapping language. One anecdote that I think supports this possibility is that ORM proponents see the ability to easily flip among different RDBMSes as a big bonus. Whereas folks who aren't fans tend to see it as a sign that the DBMS isn't being used to its full potential, since advanced SQL features (and basic rules of thumb for designing performant schemas) are almost always very DBMS-specific.

Reply on news.ycombinator.com