6 ms·
But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives
by dymk 7y ago
But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives
- pknopf 7y agoThere's a middle ground. Micro ORMs.
- chii 7y agoA micro ORM is just an ORM, written well and modularly. It isn't a middle ground - it's choosing to use a well written library. A lot of people conflate ORM's leaking because of poor designed library with ORM being a bad abstraction in general.
- scarface74 7y agoOne of the most popular Micro ORMs for C# is Dapper which is used by Stack Overflow. There is no real abstraction. You write standard SQL and it maps your recordset to an object. You know exactly what code is running. There are extensions that will take a POCO object and create an insert statement and I believe updates, but where ORMs usually get obtuse and do magic are Selects. It’s hard to generate a suboptimal Insert or Update.
- ct520 7y agoSo.. pattern I see emerging. Use orm for the common stuff and execute sql for complicated queries (like reports)
- Trisell 7y agoThat’s how I’ve done it on my last two projects. We used TypeORM for the standard repeated simple queries, and then wrote custom SQL for our complicated queries that the ORM failed at and then just executed them with the ORM. It was really nice and made for easier table refactors because we didn’t have to go through and audit every query that was calling that table.
- Rapzid 7y agoTypeORM is a step in the right direction for JS ORMs bit it's like 1/8th of the way there IMHO. A nearly fully typed ORM is possible now with Typescript and of course proxy's are out now.. TypeORM was doing too much ADHOC string building under the covers as well. I believe a SQL AST is the way to go. It can be transformed and compiled to database specific SQL allowing for things like predicate push down, optimization, and a sane way to implement db specific optimizations and extensions.
- nikolasburk 7y agoI really like your point about type-safety! I think one major issue with the current ORMs in the Node.js/TypeScript ecosystem (Sequelize, TypeORM, ...) is that they're not fully type-safe. As you mention, TypeORM is definitely a step into the right direction here, but the way how it leverages the TypeScript type system isn't where it could be. I work at Prisma where we're building [Photon.js][1], an auto-generated database client with a fully type-safe data access API. [1][https://github.com/prisma/photonjs https://github.com/prisma/photonjs]
- scarface74 7y agoAnd for ETL and data loads. An ORM isn’t going to usually do a multi insert statement or an update that involves more than one table.
- JohnBooty 7y agoRuby on Rails’ ActiveRecord, for all its heft, is excellent at this. You can use raw SQL any time you like. It was an explicit design goal from day 1. There are times I dislike things about it, and it can be quite heavy, but it’s very easy to mix and match ActiveRecord ORM code and raw SQL even within a single model class.
- leosarev 7y agoActually, DDD recommends that domain object in general should be loaded by id only, and complicated query for grid should load projection
- DougBTX 7y agoThe informal definition I have of a micro ORM is an ORM without an identity map and without lazy fetching through proxy properties. Are there any more concrete definitions?
- LoSboccacc 7y agoalso implicit row mappers so one can still do the queries manually without writing all the oo glue
- sjwright 7y ago> There's a middle ground. > Micro ORMs. And there's the mystical fourth option of simply not bothering with objects in the first place. No objects, no need to do object-relational mapping.
- goatlover 7y agoSo then you’re mapping to whatever data structure your app uses instead of objects. In OOP languages like Python, everything is some type of object anyway.
- sjwright 7y agoThat’s just a semantic game. If your language returns the result of a query as a generic array of generic dictionaries (or whatever), that isn’t mapping, nor is it object oriented in principle.
- goatlover 7y agoBut then your generic array of generic dictionaries needs to be mapped to whatever data structures make sense for your application. ORMs save you that step.
- sjwright 7y agoI've written many apps and I've never experienced what you've described. I write my queries to return exactly the right data in exactly the right format in exactly the right order—so I can go straight from the generic data structures to the screen interface or document layout. Nothing says the structure which make sense for an application can't be a generic array of generic dictionaries. If your favourite programming language forces you to go through the silly hoops of data mapping in order to do useful things with query output, I can understand why an ORM might make sense for you.
- lugg 7y agoWhy 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.
- rmilejczz 7y agoAn in house solution is almost always better than an external dependency
- nullspace 7y agoHah... I’m probably falling for Poe’s law here, but anyways... there are certainly cases where in-house is better than external dependency - specifically when your team knows the tech domain better than anyone external can... but in general well-maintained (preferably open source with a community, or a well funded company) external dependencies are almost always better. They usually would have the years of fixing edge cases and features that you would inevitably run into if you were to roll ur own.
- scarface74 7y agoThere is hardly ever a time where an in house solution is better than a third party one for cross cutting concerns. Most of the packages are open source.
- rmilejczz 7y agoThey’re also tailoring their solution to be as generic as possible. Having written OSS and also having written enterprise applications, it seems plainly obvious to me why a homegrown solution is preferred. Code developed internally is understood by the team (you may not understand the underlying implementation of a dependency), and can be tailored exactly to suit your needs (ignoring edge cases that aren’t relevant, removing unneeded features). And you never have to worry about maintainers disappearing, breaking changes being introduced, or bugged releases that you can’t do anything about. I don’t mean to sound crass but how on earth could you think this is an example of Poe’s law? What’s so extreme about being a responsible developer? I didn’t say “every solution should be developed in house” (though I think most large projects would be better for it!) obviously there’s is a cost associated with in house solutions and you should gauge that cost to see if it’s worth it for your application. But if you’re going to be working with that application for years and years to come then I highly recommend trying to write your own code instead of relying on libraries.