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 12 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 12 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.

    Cheers,

    Thomas

  • 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?)

  • 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 🙂

    http://blogs.tedneward.com/post/the-vietnam-of-computer-science/

  • 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.

    http://www.talkingdotnet.com/use-dapper-orm-with-asp-net-core/

Leave a Reply