was successfully added to your cart.

Why Don’t You Use Entity Framework?

Why Don’t You Use Entity Framework?

By March 30, 2018 Ask Tim 55 Comments

The Case for Speed, Simplicity and Ease of Maintenance

Microsoft’s data access method of choice is Entity Framework. I disagree with that choice. Obviously there are a ton of really smart people who design and build Entity Framework. There are also fellow Microsoft MVPs who I realy respect like Julie Lerman who spend a ton of time evangelizing Entity Framework. So it does seem odd that I would disagree with all of them. Let me lay out for you the reasons why and I will let you decide which way to go.

The goal of Entity Framework (EF) was to create a simple way to abstract away the database and allow developers to just work with data objects. Basically, as a developer, EF should simplify your life by allowing you to stay in C# and not think about how the data is getting into the database or back out. That’s the goal. Now, let’s talk about the reality of it. If you look at this simple getting started with EF example, you will see that you need to learn about DBSet, Data Context, Initializers, Seeds, Pluralization, and more. That’s before you take on the more complex example. That doesn’t seem simple to me. It seems like in order to avoid learning SQL, you ended up learning a whole new set of language tools. This isn’t reusing your skills, it is adding a new skill in C# for express purpose of avoiding learning a skill in SQL. Since you still need to know SQL, it doesn’t seem like a good trade-off.

In contrast, my tool of choice is Dapper from the folks who make StackOverflow. I created a whole video on it (found here: https://youtu.be/Et2khGnrIqc). I won’t go into all of the points I covered in that video, but basically Dapper is simple to use and it allows me to use stored procedures, which in turn can help me make my database much more secure.

Now let’s look at the three areas that we should consider when choosing the best data access tool for our needs: speed, simplicity, and ease of maintenance.

When it comes to speed, the speed I think is most important is application speed. How fast is it for our customers. In this category, Dapper wins hands down. You can go to their page on GitHub to see that Dapper is an order of magnitude faster than EF. Now some might argue that speed of development is important as well. I agree, but not at the expense of my customers. When it comes to development speed, EF has a better story once everything is set up. Once you have all of your configuration set, your settings tweaked, and your models built, it is pretty fast to make small changes. Dapper isn’t slow, it is just that you need to make the change in two places (your model and your stored procedure) if you want to add or drop a field.

Simplicity is another area where Dapper crushes EF. In four lines of code, I can get data out of a database and into a List<T>. Try doing that in EF. You will have adapters, context, and more and won’t even have data yet.

Finally, ease of maintenance is another Dapper winner. If I have a database developer on my team, they can work just in SQL. If I use EF, I would need to get a database developer who also knows C#. Either that or I don’t have a database developer on my team but then who optimizes the database? The C# developers?

To summarize, Dapper is quicker, simpler, and easier to maintain. It fits better into an existing organization with existing databases. It is simpler to learn. It is powerful and yet not complex. So, for all of these reasons, I choose Dapper for my data access needs. How about you?

Join the discussion 55 Comments

  • Mauricio Caterino says:

    I totally agree. I have EF as a must learn skill. But, Dapper is my choice for access and crud operations. It’s faster and simple.

  • ThomasW. says:

    Hi Tim,

    I entirely agree with you. Even better, I followed your tutorial about Dapper, and within an hour I was able to build a simple WinForm app which perfectly executed all my simple CRUD operations via stored procedures. I tried EF, and I must say that I also like it due to the graphical interface etc. but as you mentioned it requires far more effort to complete the job. Thanks for reminding me the Dapper, I must learn more about it.



  • Christian I. says:

    Hello Tim,

    At some points I agree with you. At work I use Dapper or EF depending the project. But the argument “Allow me to use “Stored Procedure” it’s a no argument. If I can avoid (that’s means almost all the time) “Stored Procedure”, I avoid. My current customer has an application with a lot of “Stored Procedure”, “Trigger” and so on …. a real sh### to maintain, business is (partially in the database), real sh### to test. You can use “Stored Procedure” with Dapper and EF.

    • Tim Corey says:

      OK, so I have a video on YouTube that covers Stored Procedures. You might want to check it out (https://youtu.be/Sggdhot-MoM). There is a lot more to stored procedures than just making SQL calls. First, they are optimized in a way ad hoc calls (which is all EF does) cannot be. Second, you can lock down your database so that users can only called stored procedures (no table access, etc.) to reduce your vulnerability and practically eliminate SQL injection. Third, they describe the proper way to interact with your database.

      A database usually does not support just one application. Nor is the application the only way people access the data in that database. Since the application is not always in the picture, putting the security and business logic in the application leaves your database vulnerable. If a user listens for your connection information (and because they are on the machine running the application, assuming it is a desktop machine, they can) and gets the database password, what can they do? In my case, nothing beyond what the application can do. In your case, anything (since an EF connection needs to be an administrator, or practically so, so that it can run full CRUD operations).

      I know stored procedure maintenance is tougher because it isn’t in the same place as C# but I would maintain it shouldn’t be. You are doing two different things (database development and C# development). Trying to combine the two is a shortcut and there are numerous penalties for doing so. These include reduced security and reduced performance. EF tries to tell you that you can eliminate the SQL Developer’s job by using it but that isn’t true. You still need to do database work, especially as you get bigger. Unfortunately, EF looks great in small scale and in development. However, have you ever tried to optimize SQL when it supports a large-scale EF system that gets hit by hundreds or thousands of users? It is a mess. With all the ad-hoc queries being called, it is hard to make anything more efficient. It is also hard to work with the database outside of that one application as well (what if a different application needs a column added?)

      • Peperud says:

        I agree with most of your sentiments about ORMs.
        However…20-25 years ago I used to be a huge follower of the “do database access via stored procedures only” (and explicitly preparing statements etc.) mantra.
        Not anymore.
        1. Optimizers are much better – there’s little to no benefit in terms of actual performance (and SQL Server user defined scalar functions are downright dreadful for performance) . Especially for simple CRUD.
        2. Maintenance is harder.
        3. Portability is a nightmare. This is a big one. Applications are moving away to different/cheaper/free alternatives like MySQL, PostgreSQL etc. Converting is costly and often it is not possible to stay with SPs in the new database.
        4. The security benefits of using SPs is not nearly that much of a consideration anymore. Web apps (the most prevalent case today) usually use a fixed connection with a dedicated user and do security at application level.

        • Tim Corey says:

          Optimizers are better if you compare apples to apples (the same query). Unfortunately, EF normally does not write good queries (more bulky, less targeted). As for maintenance being harder, this can definitely be true but it doesn’t have to be. Portability is one I hear a lot but I’ve never seen in real life. Once a company builds an application against a specific type of database, it almost never moves to a different type. Doing so would be incredibly difficult (for an application of any scale) because different databases do things…differently. Data types aren’t quite the same, storage sizes are different, and optimizations are different. As for security not being as big of a deal, I am not a big fan of this. Security is about layers and to say that the outer layer is secure so you are set is not wise, in my opinion. What if the server gets hacked and that password is exposed? What if a tech on the server writes it down? What if you accidentally leave a hole in your code and it allows a hacker disk access or access to run scripts? In any of those scenarios, the hacker now has access to everything in your database. In my scenario, they have the same level of access as a web user. The can still cause trouble, but not nearly as much as full access can (they can’t drop tables, erase history, or make unmonitored changes).

  • Paul says:

    I have to disagree.

    1) Speed – yes, Dapper is generally faster (but in 90% of apps, this is irrelevant and the other two factors are far more important)
    2) Simplity – writing a LINQ query, particularly when aggregating or joining several tables in hugely simpler than hand-crafting SQL statements.
    3) Maintenance – again LINQ wins because it is written in c# and therefore type safe and able to be included in refactoring. If you change an EF property name, it will be updated in all queries when you use refactor tools. It someone changes it manually, you get a compile type error which is quick to see and quick to fix. With Dapper, you have bits of SQL that you manually need to edit.

    • Tim Corey says:

      Here is my responses:

      Point 1 – Dapper being an order of magnitude faster than EF isn’t irrelevant unless you are building hobby apps. Taking 10 times as long to make a call is a BIG deal. A single call almost never happens in a vacuum. One process usually takes multiple steps. Those speed issues just keep piling up until your application is sluggish and the only way to fix it is to completely replace your data access layer and rewrite your application. That, to me, is a big deal.

      Point 2 – Here is the problem with this argument: it implies that a C# developer that doesn’t feel comfortable with SQL should fix that problem with more C#. Your SQL database is not just a dumping ground for data. You need to maintain and optimize it differently than you do C#. Otherwise, your “simple” LINQ statements make SQL bog down and you can’t optimize it because everything is an ad-hoc query, which makes it harder to do anything on the SQL side to make things better.

      Point 3 – I get it and maintenance when you change something is a pain if you are using stored procedures and Dapper. However, using EF implies that the application is the only client of the database. So what happens when you want to do reporting out of your SQL database (and not through your application)? If your application changes one field, you just broke every report, script, and other application that uses that database. Not only that, when you go to create those reports, how are you going to do it? You will need to create stored procedures to populate their data. In my case, the stored procedures already exist. It is much more DRY than EF. If I decide to change how a stored procedure works, it changes for the report and for the application. Sure, if I add or remove a field I’ll need to change it in the report and the application, which is a pain. That pain is unavoidable though, unless you want to argue that the only purpose for a database is to serve an application (which, in the days of big data, analytics, and more, that idea is outdated at best).

      Just to round out our discussion, you also failed to address speed (EF is an order of magnitude slower than Dapper – essentially every call EF makes is 10 times slower than the equivalent in Dapper), security (With stored procedures, I can lock down a database to only stored procedure access. With EF, you have to have full CRUD access to all tables. If Dapper’s connection string gets hacked/discovered, the user has no more permissions than the application. With EF, the user now has full admin rights.), and reusability (With stored procedures, I can use them in other applications or other “things” like reports or even direct calls. With EF, your data access logic, safety checks, etc. exists outside the database and cannot be easily reused.)

  • rledyard says:

    I see a lot of parallels to ASP.Net WebForms. Replace “You don’t need to learn SQL” with “You don’t need to learn HTTP, HTML and CSS”.

    • Tim Corey says:

      Yup. One of the many reasons why WebForms are not really recommended anymore.

    • Jonesjj says:

      I agree. I think many of these comments are missing the point. This post didn’t seem like an argument *for* Dapper. I think it was intended as a post *against* EF. The fact that you have a really good C# hammer doesn’t make everything a nail.

  • Travis Laborde says:

    obligatory “Vietnam of Computer Science” reference 🙂


  • I totally agree with you. EF is a whole new tech to learn for the same tasks which you were doing in the past with your SQL skills. It’s ok to use EF for a small project, but when there are lot more data to deal with, EF is a nightmare (personal experience). I have never been a fan of EF and also try my best to convince my customers to stay away from it. I also posted about on my website to use dapper with Asp.net core and it was really quick to get the app up and running with database interaction.


  • Jan says:

    Why not use both?

    EF Migrations can help speeding up application development, simplifying schema setup and so on, EF Linq is also a great helper for maintainable queries. When performance is needed, use Dapper.

    Both tools serve a purpose.

    • Tim Corey says:

      I think you answered your own question. If you say “when performance is needed” in relationship to an application, the answer should be “always”. There shouldn’t be a time when you say “we really don’t need performance here”. There are a couple reasons for that. First, why plan to be slow? I don’t know of anyone who says “man, this application is too fast”. Second, you cannot predict how an application will be used in the future. I’ve created a TON of applications where I thought they would be used temporarily for a small purpose and they ended up being production applications that were widely used for a long period of time. I once created a simple Access-based database application that was supposed to be used just for the summer. It was used company-wide for over a decade (maybe longer – I left the company and lost contact with those still there).

      Now there are times when you choose the less efficient route in order to gain something else. For instance, sometimes reflection is the best choice even though it is slower than other options. I get that. However, this isn’t a small piece of your application that you will barely use. This is your data. Probably the entire reason your application exists. I can’t fathom the idea of saying “it is ok to slow down the core of our application”.

      Another part of this argument is that it speeds up development. Great. So you get a one-time speed bonus (let’s forget for a minute that maintenance and debugging are harder). How many times is your application going to be used? 10,000 times? 100,000? The more your application is used, the more expensive that one-time speed bonus becomes.

      The final piece is the idea that you can always switch if you need the “extra” performance. In my experience, once you go down the EF route, you are stuck with EF. Backing it out and replacing it with Dapper or some other data access method will be incredibly difficult if not impossible. So it isn’t like you can make one choice today and change your mind tomorrow. You have to choose up front – development speed or production speed. I’ve made my choice.

      • Jan says:

        I get your point.

        But I don’t plan to be slow. Sometimes “EF-slow” is simply fast enough. Not everyone writes Facebook scale applications, sometimes a typical LOB app for 200 people must be made. And if an EF query in a UI view needs 100 ms vs. 10 ms, that simply doesn’t matter. And some people (although obviously not all people) would agree, that EF is simple, approachable, productive and fulfills the job. Not everyone wants SQL strings all over their Repositories.

        If in the same LOB for 200 people a high performing batch job is needed, one can always use Dapper for that (and even reuse the POCO Entity classes).

        EF Core performance by the way isn’t that bad anymore, see https://koukia.ca/entity-framework-core-2-0-vs-dapper-net-performance-benchmark-querying-sql-azure-tables-7696e8e3ed28.

  • Branislav Petrovic says:

    Hi Tim,

    do you have any experience working with LLBLGen Pro Runtime Framework (ORM) as alternative to EF and Dapper? There are some relevant infos that this ORM is best choice to use in LOB applications with a large number of users and data.



  • vincent says:

    You didn’t even touch on the cloud stuff and server-less computing like azure functions, where you now you have a pay for execution time pricing model, so it stands to reason that if EF is 10X slower then it stands to reason that it’s 10X more expensive to run an EF application then stored procs. Now add into the mix memory optimized tables and compiled procedures which can be hundreds of times faster and to the modern (frugal) developer this should be a no brainer. If you’re really clever it’s easy enough to query system views and run procedure meta data through the razor engine and presto, you got all the wrapper code just the way you like it. Too many rookie developers in the mix yapping about how great this tool is or that tool is. Tools don’t solve problems, people do, so invest some time into really learning and understanding SQL, you’ll be rewarded many times over.

  • Neil Hewitt says:

    You know I use dapper with SP’s for every single call. barring auth which is already built in to most boilerplate.. my dev journey saw me initially writing Sql in c# then as the core app grew and i progressed moving them into SPs for optimisation and maintenance.. then i struggled with entity because i didnt understand why i was bein pushed to learn a new way of writing code that ultimately just generated SQL something I was now pretty fluent with.. enter dapper.. I now only ever use Dapper.. it’s all I need.. my SQL queries are maintainable compiled.. easily loggable and can be modified on the fly without pushing a new release.. yes I have most of my business logic in my sps but for me that’s a huge advantage.. I’ve always felt like I must be doing this all wrong though because everyone seems to be on the entity train.. but this article and your replies to the comments literally could have come directly from my mouth. I could literally write off any challenge as to the benefits of dapper with SPs over entity within a single sentence… but I’m just baffled as to why everyone that writes c# or accesses SQL doesn’t use dapper with sps by default.. the only thing I can think is they don’t understand or care about db performance and are just following the person in front…

  • Alex Buyny says:

    Interesting article and conversation! We are currently considering EF vs a more standard approach in my company (Dapper + stored procs). Still have not decided…

    Re: (Tim) reusability of EF when you need to have report / second app on the database. How about this solution – abstract your models and repositories into a separate DLL (nuget package) and reuse it in both projects.

    • Tim Corey says:

      Regardless of which solution you use, you can put your data access code into a separate dll and then reuse it. I would definitely recommend it. If you use Dapper, you can also create a couple generic methods that allow you to extend your data access dll later as well, so that you can have additional data access code in a project that is project-specific. That allows you a lot of flexibility.

  • Adam Hardy says:

    Hi Tim,

    I’ve used EF on several projects now, and regretted it. I couldn’t agree more with your sentiments, trying to write SQL in C# invariably ends badly. All my devs are relatively full stack, meaning they can write a reasonably efficient SQL query far easily than trying to come up with some LINQ statement where if you hold your tongue right it might result in an efficient SQL statement, and that’s before getting into stored procs.

    In my mind, the argument for Database agnostic data layer simply doesn’t stack up. In my experience, the risk of the database changing is so low it’s not worth factoring in. Far more likely is having to handle multiple database technologies which EF doesn’t handle anyway.

  • Chris says:

    I’m not sure when the last time was that I ran into a functioning, senior-level C# Dev who _didn’t_ know SQL . I have never once, since it’s inception, ever heard somebody tell me they use EF as a means to avoid learning SQL – that notion seems pretty absurd to me as the basis of an argument for, well, anything.

    • Tim Corey says:

      Typically senior-level devs will say that it makes life easier (vs. not needing to know SQL at all) but the problem is that the EF argument is partly based in truth, partly based upon a twisted take on truth. Those who fully understand it may choose it because of development speed, source control usage, etc. whereas those who are newer to C# see the side-benefits (not needing to understand SQL) as a reason. This is only a slight twisting of phrases like “It enables developers to work with data using objects of domain specific classes without focusing on the underlying database tables and columns where this data is stored.” (from http://www.entityframeworktutorial.net/what-is-entityframework.aspx ). Code-first makes the water even muddier for them.

      Honestly, how many devs (junior or senior) do you think do database administration, optimization, etc. of EF-created databases? Not nearly all of them. Whether they admit it or not, they are avoiding doing the SQL work that needs to be done (even in an EF environment).

      • Chris says:

        Your point about C# Devs not doing the SQL-side optimization that needs to be done is a bit out of sync with the rest of your arguments. I would still maintain that most devs who have some time and experience in the field are no strangers to SQL and in many cases are more competent at Db design than their DBA counterparts. Your argument speaks much more to newer, less experienced devs – not the type of devs designing applications that require the type of speed difference from EF to Dapper. Any project that requires the better performance of a non-EF solution will most assuredly have the expertise on hand to know the Db optimization must be done, and to do it.

        I recently came off a contract where there were ~20 in-house DBAs; overseeing around 5 or 10 Dbs. It was a forced Db-first, sproc-driven, 60 different Schemas per Db _nightmare_. This is exactly the slug, corporate, legacy mentality that makes me cringe every single time I hear the words sproc or Db-first. Going through weeks of red tape and head scratching to effect the most minor of changes on a table or sproc or view is obscene in today’s tech realm – yet countless companies hang on to this mindset for dear life. If I sound jaded it’s because I am.

        In an ideal shop the devs would have control over the Db design and schema – and would work with a single DBA on ensuring the design allows for best-case optimization and performance tuning. Are there occasions where sprocs are better? Yes – here and there. But in a vast majority of the projects in our field, the SQL caching mechanisms are simply not enough of a factor to flip the design paradigm. EF has closed the performance gap considerably in recent years and is not the gimpy kid brother it once was. Large-scale enterprise applications and traffic-intensive websites being the primary driving factor in turning away from EF for purely performance concerns – and how many of these types of projects do most devs even work on regularly? Certainly I wouldn’t think the number is high enough to warrant a generalized down-trodding of EF.

        I would posit that EF is a faster more streamlined development & maintenance process that gives you in-code type safety and refactoring capabilities and is absolutely performant enough to suit 80% of all projects out there. The people who truly understand where EF trails off and Dapper picks up are likely the people who already know when to use one versus the other – and issuing a blanket “one is always wrong, the other always right” statement is just not accurate.

  • Yogi says:

    Hello Tim, I got to know about Dapper ORM from your post although I have been using Entity Framework 6 and Entity Framework Core. In EF 6 the .edmx file is a big headache, sometimes it get corrupted also there is no clean and quick way for executing stored procedures that returns multi-result sets. I hope Dapper has this support. I look forward working on Dapper in my next asp.net website.

  • dean wings says:

    thank you tim for a clear summary of the different approaches. Having read your post it reinforced my decision to stay away from EF. working with existing SQL server databases and porting applications to V.S C#.. looking at EF i was immediately wary of the (many) extra layers and paradigm shift from what we use already. SPs / SQL .

  • Tomy says:

    As someone who doesn’t have that much database experience with databases, I find that the showstopper for me in using Dapper over EF is dealing with complex types. Sure, it’s very easy to write queries for flat objects, however if I have more complex objects hierarchies then I’m pretty much lost.

    For example, I have no idea how to write an Insert query that will insert a Person with its associated addresses:

    public class Person {
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public List Addresses { get; set; }

    public class Address {
    public int Id { get; set; }
    public string StreetNumber { get; set; }
    public string StreetName { get; set; }
    public string City { get; set; }
    public string State { get; set; }

    In EF it’s as simple as creating the objects and calling db.SaveChanges(person) and they get stored automatically… whereas in Dapper I’m completely lost

    Again, I’m talking as a novice without much experience in SQL.

    • Tim Corey says:

      I do this in my C# Application from Start to Finish course. You insert the Address, get the ID back, and then insert the Person with the Address ID. It really isn’t hard to do once you’ve done it once or twice.

  • Khoa Nguyen says:

    I totally agree with you. I have been working in Enterprise environment for many years. For every new project, I always consider EF as a choice. But what EF is suitable for just simple CRUD application.

    EF is pretty bad at enterprise level. When the app grows and more complex requirements come, I always feel EF is a bad choice. Even traditional ADO.NET programming is far better. Recently, we have a legacy project with 5000+ stored procedures and EF completely doesn’t work at all. It throws many type of errors when mapping the stored proc.

  • Scott MacDonald says:

    Interesting but (and I am a newby to EF, etc…) from very bad experiences I have had in other programming realms involving databases I have a simple position, Dapper may be gone and unsupported at any time, Microsoft is probably going to be around for quite a while. If I am to build for the future it would seem that the logical thing would be the more broadly accepted tool. Your thoughts?

    • Tim Corey says:

      I have similar thoughts in that I’m very careful what I depend on. However, here are some reasons why I chose to embrace Dapper. First, it is supported by the makers of StackOverflow (the largest technical Q&A site in the world). Second, it is open source, meaning if they were to ever stop support for Dapper, it wouldn’t go away. Someone else could continue to maintain it (or I could) and the existing code would continue to work until major changes in C# broke something. Third, it really isn’t that much of a dependency. I know it sounds huge but if you write your data access layer correctly, you are doing very little Dapper work. Personally I have only a couple Dapper-specific methods in my code usually. If I had to change out Dapper for straight ADO.NET calls, I could probably do that in a couple hours regardless of my project’s size.

      On the other side of your argument, I want to point out something important. Microsoft as a company isn’t going anywhere. The tools they support regularly get deprecated though. Silverlight is a great example. They pushed it hard for a couple years and then killed it quite quickly. In the case of data access, I used to love Linq2SQL. It was easy to use and powerful. Microsoft killed it. Technically they merged it into Entity Framework but the reality is that the simple, powerful tool I loved no longer exists in that state.

  • Craig Mauldin says:

    I don’t think I need to learn ORM as I have been doing adding SQL to my application. But when you look for examples online to do something it seems to bring you back to EF. I don’t like the though of a framework creating the database tables. So if I do learn EF then I would have to learn it as database first not code first. But most examples are code first.

    Not sure why I need ORM other then to have the knowledge for other jobs.

    • Tim Corey says:

      ORMs make data access easier. That’s it. I use Dapper because it is built on the idea that performance is key. You still need to build your database yourself. You could write your own ADO.NET connection to SQL and it will be fast but then you have datasets and datatables to convert into C# objects, which is tricky. ORMs do that for you.

  • Lee says:

    LINQ has its place, but Sprocs by and large are far superior for medium to large projects.
    Go with EF/LINQ if its a quick small project.
    The security benefits and total control of Sprocs far outways development speed in my opinion providing its planned well.

  • marcos says:

    EF is simpler to use, requires a bit more configuration but that’s fine it’s one time.
    and most of the time it’s acceptable for the 70% of the uses cases
    var users = db.Users.AsNoTracking().Where(…).ToList();

    Dapper which is am a big fan of, is off course faster, but it lacks:
    1. the database abstraction support, in my case I’ve used to work with more than one db provider for the same app for instance Sqlite and SqlServer, so I should write two different syntax for both vendors.
    2. building dynamic queries is too difficult, you have to deal with string concatenation and …. while in EF this is totally doable thanks to `IQueryable`
    3. In EF you can load nested entities which save a lot of time `db.Users.Include(x => x.Country)`, and simplify your code, while in Dapper you have to rewrite your queries with join.

    I found a mid-way approach, using a Query Builder which is built on top of Dapper https://github.com/sqlkata/querybuilder.

    • Tim Corey says:

      Yep, EF can be a lot faster in development (once you get past the configuration confusion) but the production speed is slower. That’s the choice you have to make: do I want faster development time (which happens once or twice) or faster runtime in production (which hopefully happens thousands of times)? For me, the choice is almost always production speed (and security).

  • James says:

    Hello Tim,

    I was just building an app using Dapper and SPs, and looked at my parameters and thought that If I needed to add a new field to the table, there will be a number of places (SP, C# Parameters) to change in C# and TSQL code.
    I was considering EF because of this, but after reading this article and the comments, I think I’ll stay on this path. But how do I solve this problem?

    • Tim Corey says:

      This is the work you do in exchange for speed in production. You will have to change each place (typically 2-3 places). What this does, though, is it encourages good design up front, which is a benefit. If your database is constantly evolving as you code, you probably didn’t spend enough time planning out your application.

  • Anthony says:

    I’m a .Net web app developer working in a Business Intelligence team, so a lot of our work is reporting and data warehousing. I only transitioned to MVC from WebForms about 18 months ago(!), after I discovered Dapper. Learning MVC plus EF plus LINQ was too big a jump, and it all just felt too complicated and constricting for what I do. Dapper keeps things simple and elegant. I write the SQL and the Stored Procedures, and add the indexes if need be, sometimes with a little or a lot of help from our SQL gurus.

  • Rishi kumar says:

    I totally agree with you, Tim Corey. I work for a company as a developer Dapper is faster than EF. And also a big reason to choose the Dapper for me is the Azure function which cost based on the execution time. But my concern is how to handle the database migration if I use Dapper EF helps a lot to make any changes to the database and rollback. I want to you that please suggest me the way to handle database migration without EF which support multiple databases like RDMS and No SQL databases which will be easy to change any time your database from one to another.


  • Jerry hulsey says:

    Ef has made me question if I have thrown away 4 years of college learning. I have been after it for 3 months and still do not understand it or can I really get it to work. I just want to connect to databases and leverage them in web applications. Now I am just confused and defeated.

    • Tim Corey says:

      Don’t get discouraged. EF is actually quite advanced. Learn Dapper and you can enter the data access realm at a lot lower entry point.

  • Gint Batura says:

    Tim, thank you for confirming what I had suspected for about a year now. EF, although cool in certain situations, either needs to evolve more, or should be only used in certain types of projects. I find I have to create stored procedures and consume them in EF as I improve the application I am working on. I have used a very “stored procedure centric” data access layer for over 13 years, very successfully on many other projects. I enjoy the raw power of tweaking stored procedures, and related database objects, when performance issues arise. It is exactly where this stuff should be done. I will be checking out Dapper because of this article.

  • Fernando says:

    I haven’t got much experience in programming. But I can easily write queries and I feel secure of what I am doing. When I do it, I don’t take too long fixing bugs. EF scares me because it even frightens my programming master (taught me CRUD in EF) when the code crushes! Thanks for your advice Tim.

  • Vibs says:

    Dapper also handles multithreading issues and scenarios very well. Excellent post by the author. I also echo his sentiments.
    Dapper is for Production, EF is for R&D and for making your Post Grad Comp Engg Projects 😉

  • Todd Hilehoffer says:

    We actually use ADO.Net and stored procedures. We have a data access class we use to simplify it. Stored procedures just make it so much easier to make a better performing, more secure, more maintainable application. Your queries select just the data your need and you can view the execution plan make sure it is indexed properly. SQL traces are useful because the SQL is easy to read. Debugging problems with generated SQL can be so frustrating. EF is cool. I have used it successfully. I just don’t prefer it.

  • Daryl L. says:

    Hey Tim,

    Novice developer here from the Philippines. 🙂 Learned a lot from your blog. Currently using Dapper on one of our applications, but was planning to use it together as a hybrid with EF using CQRS. So EF will mainly work with creating, updating and deleting records while I use Dapper for queries. I’d appreciate it if you gave me your thoughts on this. Thanks!

    • Tim Corey says:

      I would say that typically doubling your complexity doesn’t make sense. There are cases when it does, but they are rare. For example, StackOverflow (the creators of Dapper) actually use EF Core for about half of their data calls. They use Dapper for the other half. They base their decision in part on the need for speed vs. the need for simple upgrades. That is a huge project, though and it is super-optimized.

  • kuldeep says:

    This was really nice discussion and blog °!! Like always your blogs and videos are very helpful. I am still not sure, what i would choose if i move to bigger enterprise based projects. however, I think one has to know in and out when they decide to go for EF , because in our project we are facing performance issues sometimes with EF. Clearly it also have to do with how data access code is written.

    Moreover, i think if we already have SPs in place and an application is being migrated to new tech stack, then sticking to a non EF based approach is best !

    I would not want to touch those SPs that are production tested already !

  • andrew says:

    How about using SQL directly and not using EF Core or Dapper ? Thanks.

    • Tim Corey says:

      You can connect to SQL using ADO.NET, which is about as direct as you are going to get. However, it is more complicated than using an ORM tool like Dapper or EF.

Leave a Reply