4 ms·
I think the strongest argument for or against an ORM is that it changes the structure of your code, how you reason about your data. Things like performance, ea
by tored 6y ago
I think the strongest argument for or against an ORM is that it changes the structure of your code, how you reason about your data.
Things like performance, ease of use, reusability, schema generation etc are minor points and not the big issue you need to think about.
Personally I feel that an ORM will lead your project in the wrong direction and your database schema will suffer.
ORMs will usually mix both reading and writing within the same class, but those are not the same thing.
Readers will have different views of your model depending on who they are or what time it is. Writing on the other hand must fulfill your constraints.
Other common mistakes of ORMs is mapping one class with one table, but your data consist of series of relationships, that can’t be explained with a class.
An ORM creates an illusion that your data is actually the class entities in your repository. This can have the effect of creating constraints in your own mental model of your data, thus making it harder to evolve your schema because you are to fixed on how your classes are designed.
- IggleSniggle 6y agoGreat comment! I’ve been thinking about a tangentially related subject: TypeScript is like a relational database (and other structural statically typed languages) of your application behavior, allowing you to query the current possible states of your data at any given point in your application code. I’ve been thinking about this more since TypeScript got template-string generics, and folks have experimented with eg type-checking SQL strings back into application code. This is the piece that draws me to an ORM: that it brings the “relational model” into application code, NOT the “object” part of an ORM. Does anyone have any opinions about which language ecosystems create the most effective type-mappings between a RDBMS and application language? Part of me also wonders if there’s a ton of time lost on mapping between languages like this when the tooling that’s really missing (afaik) is better tooling for producing, consuming, and generally interacting with SQL and db schemas as the data runs through your application pipeline.