I've only ever used the method syntax for LINQ. I'm not a fan of having another "embedded" language inside my host language, especially since what is returned e

I've only ever used the method syntax for LINQ. I'm not a fan of having another "embedded" language inside my host language, especially since what is returned eventually needs to go back to C#. When I'm not using an ORM like Entity Framework or Dapper, I still prefer to place my data access logic with SQL into a separate abstracted project so it doesn't spill across my application (and can be replaced if I were to require a different RDBMS, although this has only happened to me once in 20 years). For more junior devs using LINQ, setting them up with a profiler and the debugger I believe helps makes more sense about what is going on behind the scenes. Sometimes it's helpful to have them code using for-loops and standard C# logic, and then compare to how you'd implement in LINQ, to see the positive and negative of both approaches.