What's the difference between using raw SQL queries to manage objects in Dapper and Entity Framework?

asp.net-core dapper entity-framework orm sql


From my reading, Dapper is suppose to be more SQL friendly, but Entity Framework (EF) allows raw SQL. I typically use SQL, but I like some of the things in EF. Many of my queries are fairly complex, cover more than one database and database engine, and most are not just simple CRUD.

When it comes to using SQL, what is the difference in how an object is handled? When I issue a query, if something comes back and I assign it to a <dynamic> List type, are they both the same?

I am using ASP.NET Core 1.x.

1/23/2017 4:47:15 PM

Popular Answer

If you're using EF to issue SQL requests, you're not really using EF. The calls are line for line equivalent to ADO, and the loading of the result object, which you get to define and maintain, is trivial. Lots of folk use EF, but then use Dapper for the times they want to do raw SQL. Dapper caches the mapping of the result-set to POCO, so subsequent queries run faster. I don't think EF does this. Also the parameter handling is much nicer in Dapper.

But you're still stuck with SQL in string literals, every error is a runtime error and you have to write and maintain your result POCOs. I contend you'll be happier and live longer if you use QueryFirst (disclaimer: which I wrote). Your SQL in a .sql file, syntax validated as you type. Your POCOs generated at design time from your query results. Your queries continually integration tested, and numerous other benefits which I'll be documenting shortly!

1/24/2017 10:17:44 AM

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow