5 ms·
Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's
by jeswin 3y ago
Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's Entity Framework (EF). EF does something fundamentally different, while the rest are all some version of Hibernate with a different API or Programming Language.
EF converts your code into SQL with the help of the compiler, and is not purely a runtime affair. This is what makes it relatively more usable.
To illustrate, if JS/TS were to approach the problem in a similar way, you'd do this:
1. Allow queries to be written like this:
const bangaloreanStudents = await db.users.filter(x => x.city === "Bangalore" && x.age <= 20);
2. Use acorn/espree to parse this into an AST
3. Convert the AST into SQL, hand over to runtime helpers.
Doing so will allow queries to be written in the most natural way possible.
- city41 3y agoKnex is probably the closest thing js has to this. It's not an orm though, just a query builder.
- jeswin 3y agoKnex is quite different iirc. I was saying that ORMs should make use of parsers and modern language features (such as first class functions) to offer a unified interface to collections in memory and collections in the db. Essentially treating the table as a list on which you can use operators you're already familiar with. By doing so, your core API is timeless. Because you didn't invent an API.
- CharlieDigital 3y ago.NET and EF Core is the platform that most teams probably want but .NET and C# can't quite shake it's pre-Core image. It always strikes me as odd that teams can embrace GitHub, TypeScript, and VS Code and then react negatively to C# and .NET being Microsoft platforms. EF Core is perhaps the most powerful, most mature ORM at this point. .NET Web APIs are incredibly productive and performant with really good DX. C# isn't that far off from TypeScript syntactically and structurally. I feel like teams that are "graduating" from TypeScript on Node probably want C# on .NET but end up exploring Go or Rust instead.
- spion 3y agoMS should've dropped the .NET branding once it became cross-platform.
- CharlieDigital 3y agoAbsolutely. Rebranding would have helped in sooo many ways, even for the devs that moved forward from .NET Framework. For starters, it would have at least made search results less confusing and more contextual. There were years of confusion between .NET Framework, .NET Standard, .NET Core, and .NET 5. From a basic SEO perspective, rebranding would have been huge. It was a huge mistake to not rebrand it entirely.
- lpapez 3y agoFor me that's not the primary reason. I was discouraged from learning C# because of the sheer number of keywords and concepts in the language. Contrasting this with Go where I landed a gig after two weeks of learning by myself and felt productive right away.
- CharlieDigital 3y agoThe thing is, if you're comfortable with TypeScript, it's really more or less just a small step to C#; the Venn diagram of the most commonly used keywords between TS and C# has a high degree of overlap. A small repo here: https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp And a practical example of a Playwright web scraper in C# and TypeScript: https://github.com/CharlieDigital/playwright-scrape-api https://github.com/CharlieDigital/playwright-scrape-api "Too many keywords" is the weirdest objection to a programming language versus actually using the language to build something practical. Edit: I'm actually curious as to which keywords you personally found the most challenging to grok or what tipped the scales of "this is too complicated".
- kjuulh 3y agoI've been burned by EF more times than I'd like, the most recent (it has been a few years), was the change in default to single queries, instead of split queries. Which absolutely destroyed our performance, until we figured we should turn single query off. EF Core expression trees are nice, however, the change tracking behind the scenes are an absolute menace. I've gotten errors more times than I'd like, because EF Core had loaded a key in its store, and another query got the same key, resulting in an Exception because both touched the same record in the change tracker. Even if it was two separate requests. I've become a purist sort of, using sqlc for golang, dapper for c# and sqlx for rust. ORMs are 'fine' for simple crud apps, but once you go a bit deep in the sql, it becomes impossible to reason about. Telling an engineer that they can just run `explain analyze` on their query, and them having no idea how to actually reproduce their sql is not great. This is also just my opinion, I've been in the same place, I used to love EF, but now I dread having to debug that stuff =D Last time it was sending a non pointer to gorm in golang, panicing the application :,)
- dimgl 3y agoWhoa, no. I massively disagree. Entity Framework is, by far, the worst ORM I've ever used.