[PH95VuimJjqBqy]

> Most people never learn databases, and most people who do are idiots working on enterprise three-tier architectures

Tell me how you really feel :)

My biggest problem with ORM's is that it causes people to sprinkle the ORM code throughout their codebase but they'd never do that with SQL, they'd want to try and sequester it to a system whose responsibility is the retrieving and updating of data.

It puts people into a poor mindset around their data.

[feoren]

That's like saying: my problem with Functions is that people sprinkle them throughout their codebase, instead of having one single place where all their Functions are defined.

For most applications, "Retrieving and updating data" is the entire point, or at least a deeply fundamental part of how they work. It shouldn't scare you that such a core function -- the entire reason your application exists -- is "sprinkled around" your codebase. It should scare you if it isn't! I think the reason it scares you is because you imagine the performance nightmare of every random function possibly hitting the database N times. That's using an ORM terribly. Good ORMs let you plan database actions, and compose those plans.

Guys, you really, genuinely, don't have to choose between (a) writing SQL strings in code, and (b) using an ORM badly. You can truly do better!

[PH95VuimJjqBqy]

putting repeated data requests behind a function is what I'm suggesting...

sprinkling your ORM code all throughout your codebase is the equivalent of NOT using functions but instead copy/pasting the implementation everywhere it's needed.

Most ORM's recognize this is a problem, which is why they often try to bake in some sort of solution for re-use, only it's always done badly. They'll generally attach it to the model and it will turn into some sort of unobvious behavior or they'll attempt to be able to attach SQL fragments by name. What it ends up doing is effectively spreading an SQL query over several files. Often by convention so there's no real way to know if part of the query is going to be in file X without just checking or knowing ahead of time.

[blagie]

I kind of disagree. If you're using an ORM, the ORM is the abstraction layer which should be sprinkled throughout the code. You shouldn't wrap a layer in a layer.

If that's the right abstraction, use an ORM. If it's not, don't.

If all you have are lists of items (a todo list, a set of employee records, a set of products), an ORM is a fine abstraction. If you have or expect to do something more complex, it's probably a bad abstraction.

[PH95VuimJjqBqy]

> If you're using an ORM, the ORM is the abstraction layer which should be sprinkled throughout the code. You shouldn't wrap a layer in a layer.

preventing people with this belief from sprinkling ORM code all throughout the codebase is reason enough to ban the use of an ORM.

The specifics of how you retrieve data is an implementation detail. If someone wants to use an ORM have at it, but don't sprinkle it throughout the codebase, place it behind well defined functionality (behind a system dedicated to pulling data).

The fact that ORM's have their own query language should be all you need to know.

One could easily argue that you should be able to manually interact with db readers all throughout the codebase, after all, it's an abstraction.

But no one would ever actually argue that. Like such forward-only db readers, ORM's are a way to pull data, they are not the abstraction layer for pulling data for your application.

[blagie]

> The specifics of how you retrieve data is an implementation detail.

Correct.

> (behind a system dedicated to pulling data).

That's the textbook definition of a good ORM.

> One could easily argue that you should be able to manually interact with db readers all throughout the codebase, after all, it's an abstraction.

It depends on the abstraction they present. SQL throughout the code would be a train wreck. On the other hand, something like:

* A stored procedure to have a filtered list of gizmos...

* Mapped onto an AJAX or a function call in a data layer...

* Being called whenever one needs a filtered list....

is the way to do it. If all you have are tables of simple data, that's exactly what a good ORM would do.

[PH95VuimJjqBqy]

right, I gathered from the first inane response that you believe anything that pulls data is an ORM.

That's never been how the acronym was defined. The reason you're now trying to define it that way is because the only other alternative is to admit you're wrong.

"what if that subsystem is pulling data from AS400?" -- still an ORM!

"what if that subsystem is pulling data from an INI file?" -- still an ORM!

"what if that subsystem is pulling data from an IOT device? via the MQTT protocol" -- still an ORM!

------

The difference between an ORM and what I'm describing is that the subsystem I'm describing actually abstracts the where and the how, an ORM _is_ an implementation detail. This is why sprinkling ORM code throughout your codebase presents a problem, it's akin to re-implementing the code to pull out of an INI repeatedly instead of putting it behind a function with a single implementation.

Now go away.