What is the difference between how objects are handled in Dapper and Entity Framework - with raw SQL queries?

Question

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 quer

Answer 1

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!

Answer 2

There may be some performance differences between the two but with raw SQL queries both will populate your IList (of whatever) just the same. If you are planning to write your own complex SQL for most/all database interaction then dapper may be a better choice for you since it doesn't come with all the overhead of EF. On the other hand, if you want to take advantage of things like Code First Migrations, change tracking, etc. or you intend to do most of your database work in code (not raw SQL) then EF makes sense.

That said, your best bet may be to spend a little time with both. You may find it won't take long to make a decision once you start playing with them.