undefined | Better HN

0 pointsfeoren2y ago0 comments

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!

0 comments

PH95VuimJjqBqy2y ago

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.

blagie2y ago

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.

PH95VuimJjqBqy2y ago

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

1 more reply

j / k navigate · click thread line to collapse

0 pointsfeoren2y ago0 comments

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.

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!

0 comments

PH95VuimJjqBqy2y ago

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.

blagie2y ago

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.

PH95VuimJjqBqy2y ago

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

1 more reply

j / k navigate · click thread line to collapse