24

I am trying to use dapper-dot-net to speed up some area of my asp.net mvc application. I am using EF5 Code first also.

Since dapper-dot-net is just some extensions for IDbConnection, can i just use 

DbContext.Database.Connection

to use dapper-dot-net? I test it is working. However, i am not sure this is the right way to use it? Especially, when I use that way, will Entity Framework still has some impact that could hurt the performance?

liuhongbo
  • 2,051
  • 4
  • 22
  • 29

3 Answers3

19

Using Dapper could be a significant performance improvement in certain scenarios.

You can share the EF connection with Dapper. However (although unlikely to be a problem) you should be mindful of concurrency issues (e.g. due to attempts to associate multiple data readers with the same connection).

If you do run into such issues, you have the option of giving a new connection to Dapper using the connection string (DbContext.Database.Connection.ConnectionString), instead of sharing the connection.

Eren Ersönmez
  • 38,383
  • 7
  • 71
  • 92
  • 3
    While *true*, this is unlikely to be a problem in most scenarios - threading *certainly* is unlikely to be a factor, so that mainly leaves the risk of there being an open data-reader - that is pretty easy to spot (the error is not very subtle) – Marc Gravell Jul 30 '13 at 07:26
  • 5
    @MarcGravell I'll take your word for it :) But isn't it just safer to always give Dapper it's own connection (instead of using the EF one)? Or is there a disadvantage to doing so? – Eren Ersönmez Jul 31 '13 at 20:24
13

Yes, you can use it that way. Since Dapper is just working on extension methods, you can use it for the performance-sensitive areas of your code. And you can continue to use EF for other areas of your code. The queries that you have that are still using EF will not be as fast - but at least the queries using Dapper will be faster.

Steve Michelotti
  • 5,223
  • 1
  • 25
  • 30
  • 2
    Based on hard experience, by "faster" we mean "two or three orders of magnitude faster". I had one highly optimized query in Entity Framework that took 10 minutes, after converting to Dapper, it took a fraction of a second to complete a query 20x the size and complexity: http://stackoverflow.com/questions/9350467/how-do-i-write-one-to-many-query-in-dapper-net/30080951#30080951. – Contango Jan 25 '16 at 16:21
  • @Contango Was that with EF's AsNoTracking? – Ian Warburton Oct 04 '17 at 12:10
  • @Ian Warburton Not sure - but regardless, Dapper's performance leaves Entity Framework in the dust. Having said this, Dapper is mainly geared towards reading data, so if you want to write into a database, then I guess Entity Framework would work if one is happy with inefficient, mediocre performance that can support perhaps 10 simultaneous users. – Contango Oct 04 '17 at 14:14
  • @Contango Why only ten? – Ian Warburton Oct 04 '17 at 14:17
  • 1
    @Ian I've yet to see any examples of Entity Framework being anything less than 10x slower compared to a Data Access Layer designed to be fast and efficient (i.e. within 50% of the theoretical maximum speed of a reasonable SQL query on some given hardware, using your language of choice). It may do 10 or 50 users - but it would struggle with 100 and certainly couldn't do 1000 or 10000. When I'm talking about "users", I'm more implying simultaneous users that are putting some load on the database. – Contango Oct 10 '17 at 13:10
2

I think you have to rethink about the question. Increasing performance via changing the ORM is not a good technique. It is correct that dapper is faster and lighter than EF but this does not mean that to increase the speed of your application its better to use the dapper. EF is powerful enough to handle the whole data layer if you suffer from performance you have to introduce new feature like caching or no sql db.

you have to see that changing from EF to dapper how much will save time for you ? and how much speed can caching bring to your application.

and adding dapper has other expenses: how would you manage the transaction while you have to point of save and update how you are going to solve the roll back situation, what about the Unit of Work and Repository pattern.

These are the factor that you have to examine before deciding to go for Dapper.

Meysam
  • 555
  • 1
  • 3
  • 16