2 ms·
> The broad applicability of this approach has been proven to work by EF being the defacto DB access method in the .Net work (over 15 years now). It's only the
by mythz 2y ago
> The broad applicability of this approach has been proven to work by EF being the defacto DB access method in the .Net work (over 15 years now).
It's only the defacto DB access method in .NET because that's what Microsoft's EF library chose and .NET ecosystem just uses the default MS option but EF's influence doesn't extend outside of .NET. AFAIK no other .NET ORM does this including our .NET ORM [1] which litdb is the spiritual port of.
[1] https://docs.servicestack.net/ormlite/ https://docs.servicestack.net/ormlite/
- jeswin 2y agoThe approach has more to do with C# the language, and the Code-as-Data principles it explored and executed well. I had seen various ORMs starting from the early 2000s (Hibernate etc), and when C# added Code-as-Data into the mix my jaw dropped. Like a bit of Lisp in a mainstream language, with mainstream applicability. Nothing wrong with your approach, I was just arguing that language-native query patterns (such as customers.filter(c => c.country === "Chile")) can be appealing. And at the same time, reachable with current JS/TS tooling. But like you said, it may not be the direction litdb wants to go.