4 ms·
Why not? 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 abst
by lugg 7y ago
Why not?
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.
- notyourday 7y agoYou just said "you know, if you wanted to have a shitty burger, you can get it right there for half the price of a national chain and it will be at least as good"
- scarface74 7y agoI’ve never seen a homegrown ORM that was better than a third party one. Whenever there is an issue - and there are always issues - you have to dig into the code, because they are never documented well. There is usually a feature that no one thought about and then you have to make modifications to the custom ORM and you get an even bigger mess.
- LeonB 7y agosort of agree but also: the good third party ORMs started life as homegrown ORMs.
- scarface74 7y agoEntity Framework didn’t.....
- collyw 7y agoUsually third party stuff has documentation. Home grown stuff often hasn't. And usually better tested.
- lugg 7y agoBetter is a subjective term. I wouldn't say what I built was a better ORM. But I would 100% say it's a better solution to the problem I faced. It didn't get in the way of writing SQL, but it did reduce the boilerplate and repetitive gruntwork. "Issues" - no, it was a function call deep and incredibly clear and close to what was happening.
- mbell 7y ago> I've used hand rolled pseudo ORMs before. Is your pseudo ORM as well documented as a commonly used ORM? Can I google (or search your wiki) for common issues?