EF ("entity framework") is the ORM. LINQ lets you write queries against any collection, such as a Dictionary or a List. So I write lots of "listOfFoo.Select(x => x.Name).ToArray()" style code with it, which compiles down efficiently.
These days "pipeline oriented programming" (which is what LINQ is) is seeping into many modern programming languages like Rust, although array programming languages are still (unreadable) kings at it.
LINQ is just the way .NET calls iterator expressions that are a staple in any language that claims to be good and modern.
There are two main interfaces in .NET that have different behavior:
IEnumerable<T> which a sequence monad, much like Seq types in FP languages or IntoIterator and Iter (IEnumerator<T>) in Rust. This is what you use with whenever you 'var odd = nums.Where(n => n % 2 is 0);`.
IQueryable<T> which is what EF Core uses for SQL query compilations looks the same as the first one, and has the same methods, but is based on something called "Expression Trees" that allow runtime introspection, modification and compilation of the AST of the expressions passed to Select, Where, etc. This existed in .NET for ages and really was ahead of the time when it was introduced. You can write a handler for such expression trees to use LINQ as sorts of DSL for an arbitrary back-end, which is how EF and now EF Core work. You can also compile expression trees back to IL which is what historically some of the libraries that offer fast reflection relied on. Of course this needs JIT capabilities and runtime reflection, which makes it AOT-incompatible - calling .Compile() on such query in a JIT-less application will be a no-op and it will be executed in an interpreter mode. It is also difficult for the linker to see the exact types that are reflected on which means you have to annotate the types you want to keep and AOT compile code for. Which is why this mechanism is largely replaced by source-generation instead, closer to how it happens in C++, Rust, etc. An example of this is Dapper AOT.
