281–290 of 654 posts
Earlier quoted context omitted.
Even more advanced programmer: writing the ‘boilerplate’ queries out manually takes barely more time than composing them in an ORM, means less indirection, saves me a major dependency, and encourages me to think intelligently about each query no matter how boilerplate they might seem at the surface. Super-advanced programmer: allowing my database structure to be influenced by the needs of an off-the-shelf ORM will ma…
[deleted]
Earlier quoted context omitted.
Yep, also current rails dev here and this is also what I do :) Learning SQL with an ORM does remind me a bit of learning memory management with a garbage collector: helps you make better choices as to how you put things together, even if you never directly use the know-how.
Good to see y'all Rails developers out there, enjoying work and getting things done.
Earlier quoted context omitted.
I really don't get why people feel like non-ORMs cause boilerplate. I write the same amount of code using Micro ORMS. Type safe. No SQL. Very happy.
But Micro-ORMs are ORMs. And you're right, they do remove a lot of boilerplate.
Not in the traditional sense.
> And yes, they do remove a lot of boilerplate.
Here is all the "boiler plate" you'd need to use something like OrmLite with C#.
Type safety. No boiler plate. No abstractions. Errors are a result of the underlying data storage.
This is where it's at. The sweet spot.
Beginning programmer: ORMs let me write code without learning SQL! Intermediate programmer: ORMs just get in the way! SQL isn't that hard after all. Advanced programmer: I write a lot of SQL, but I use ORMs to cut out most of the boilerplate.
Even more advanced programmer: writing the ‘boilerplate’ queries out manually takes barely more time than composing them in an ORM, means less indirection, saves me a major dependency, and encourages me to think intelligently about each query no matter how boilerplate they might seem at the surface. Super-advanced programmer: allowing my database structure to be influenced by the needs of an off-the-shelf ORM will ma…
Also, the ORM allows me to specify models that are not only used for structuring the database, but also for validation of incoming JSON requests and easily serialize queries back to JSON.
Earlier quoted context omitted.
ORMs make the simple things simple, and the complicated things impossible.
ORMs let you drop into SQL whenever you need, usually in a way that is fully compatible with the model, so that's entirely false.
With any of the ORMs I've used, as soon as you do something even slightly unorthodox like using a view, you're on your own.
Earlier quoted context omitted.
Sometimes you just should live with duplicated code. It's OK.
Well sort of. In my view, duplicate SQL chunks that have defined business logic should either be a new table/view or extremely well-documented with really rigid communication policies for changes. For example, a company with many data analysts/scientists who may each be writing their own queries. As a basic example, the definition of some “very important” company metric changes, then there would need to be a large nu…
It also sounds like you would be well served using a service abstraction at that point to remove the data layer from client scope entirely.
The "model changes, now we have to change it every where" isn't going to be solved by abstraction, it's only limited by the amount you're willing to limit access to the underlying model, if you need that information, you need to share the model.
The best solution to this I've seen in practice is domain modelling, colocating shared code near other users. When things get too distant you start using anti corruption layers which allows more flexible model changing.
But at the end of the day this is essential complexity, orm, or any other solution is never going to be able to hide the fact that you need information elsewhere in the system to be useful.
Earlier quoted context omitted.
Sometimes you just should live with duplicated code. It's OK.
But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives
I've used hand rolled pseudo ORMs before.
I prefer just plain SQL but for the application I had there was a common access pattern that was worth abstracting out in a DRY sense.
That doesn't mean I want or need a complete ORM. Just a consistent access at certain table types.
This was my position for a while. ORMs introduce a layer of magic which obscures what's actually going on under the hood. I decided I would just make raw SQL queries and handle mapping data explicitly. I quickly ended up with a lot of duplicated code. So then I thought, "Well ok, I should add a bit of abstraction on top of this..." I started coding some simple functions to help map the tabular data to objects. One th…
ORMs are terrible in this sort of world since they tightly couple the application to the data. But if you will only ever have one application anyway the abstraction of a separate schema is pointless.
Earlier quoted context omitted.
Ya I’ve heard this one a lot. It’s kind of funny to say and does humorously underline the complexity of the problem but people take it seriously. So to take it seriously for a second: There was no good reason to be in Vietnam; even taking the stated rationale as a given, which many people did not, it was a concern many levels removed from the actual safety or functioning of American society. ORMs in contrast achieve…
Tbh you could easily claim that the explicit goal, mapping to objects, is incorrect. The real value is to reduce the damage of the SQL language itself — the unnecessarily ordered clauses, the arbitrary inconsistencies in syntax, the worthless parser errors, the lack of any static typechecking — which cause so much code bloat and debug headaches. There are two reasons to use the ORM: to not learn SQL, and to generate…
In http://p3rl.org/DBIx::Class perl has had such a thing for over a decade now.
It makes me cry that nobody's ever adequately cloned it into other languages. Eventually I'll probably do so myself.