2

I know you can access the raw SQL generated by Linq To Sql, but is it possible to use Linq To Entities to build a query and then access to generated SQL?

The reason I need to do this is because I would like to use Linq To Entities instead of a query builder, and then pass that SQL query onto Dapper which is much faster than the Entity Framework. Does this approach make any sense?

Oh, and I need it in .NET core. The linked duplicate question is about the same thing but for .NET framework.

Say I have something like this:

        // dummy Entities
        DbContext context = null;
        DbSet<Student> students = null;

        // my Linq To Entities query
        var student = students.Where(st => st.Standard == 1)
                                .Select(st => new {
                                    Id = st.StudentId,
                                    Name = st.StudentName
                                });

        // how do I access the SQL for that?
Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
Crimson7
  • 61
  • 3
  • 6
    Why would Dapper be faster running the same SQL? No, it doesn't make sense to me to use EF just to get T-SQL that you pass to something else. – Crowcoder Mar 08 '19 at 12:13
  • 1
    The question itself is based on a false assumption - that Dapper somehow uses a different API to query the database. Both Dapper and EF Core use *ADO.NET* to execute any queries. Dapper won't execute that statement any faster. Dapper won't be able to run the query at all though. EF Core generates parameter names that can't be quessed in advance. – Panagiotis Kanavos Mar 08 '19 at 12:22
  • 1
    @Crimson7 this sounds like an XY problem. You have a performance problem and assume that Y is the solution. When that doesn't work, you ask for Y instead of the actual problem X. What is the *actual* problem? Performance of *which* query? Read-only queries just need an `AsTracking()` to disable entity tracking. *Complex* reporting queries probably need a different schema or mapping to views. ETL queries are unsuitable for ORMs in the first place. If you want to load an object, change it and persist changes, Dapper won't help at all. – Panagiotis Kanavos Mar 08 '19 at 12:28
  • @Crimson7 just like screws, the use case matters. Slot heads, Philips, Allen, each has its use. Using the wrong kind of screw or wrong screwdriver will create problems. It's not the screw's or screwdriver's fault though – Panagiotis Kanavos Mar 08 '19 at 12:30

1 Answers1

0

You can view the SQL code generated for queries and change processing by using the Log property. This approach can be useful for understanding LINQ to SQL functionality and for debugging specific problems.

you can log your SQL into the console, or a file by setting the Log field with your preferred stream

    db.Log = Console.Out;


   // my Linq To Entities query
        var student = students.Where(st => st.Standard == 1)
                                .Select(st => new {
                                    Id = st.StudentId,
                                    Name = st.StudentName
                                });
Or Yaacov
  • 3,597
  • 5
  • 25
  • 49