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