
Choosing an ORM strategy - fogus
http://lostechies.com/jimmybogard/2012/07/20/choosing-an-orm-strategy/
======
sophacles
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.

~~~
true_religion
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.

------
bborud
I have a brilliant ORM strategy: don't.

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

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

~~~
jakejake
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.

~~~
r00fus
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.

~~~
jakejake
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.

