Choosing Between Entity Framework and Dapper
Two of the largest players in the .NET ORM space are entity framework (11k github stars) and dapper (14k github stars). Entity framework is the Microsoft backed ORM based around 1-1 mappings between C# models and SQL objects. Dapper is built closer to the SQL language, where SQL queries are written in your C# code and the parameters/results are mapped back and forth to your C# models automatically.
With these two great choices available, it can be difficult to decide when one is warranted over the other. In this article we’ll lay out similarities, differences, and what considerations I make when choosing one over the other. If you’re not sure, you can always use both in the same project.
Contents
Similarities
There are a lot of common attributes between the two ORMs, and a lot of the concepts you’ll need to understand in one will carry over to the other.
Model Mapping
Each ORM will handle taking the results of SQL queries and mapping them into your C# objects automatically.
Query Parameterization
With SQL injection still among the top vulnerabilities in web applications, dapper and EF can handle query parameterization for you.
Connection Management
Both will manage your SQL connection pool and reuse connections as appropriate.
Executing Custom Queries
Although dapper has better support for this, both ORMs provide functionality to run custom SQL queries and read those results back into C# models.
Pricing/Licensing
Both libraries are free and open source.
Community Support
Both libraries have a vast community behind them, which provide continuous updates as well as documentation and forums for getting help.
Differences
Although each library has a lot in common, there are a few developer and technical differences between the two ORMs to keep in mind.
Developer Experience / Maintainability
Entity Framework
EF comes with a variety of tools for developer productivity. Whether you’re taking a code-first approach or a database-first approach, there are tools to generate SQL tables or C# models and a db context. This can save a lot of headache when trying to keep your models and database in sync as changes are made. EF also saves developer time by removing the need to write queries.
Dapper
Compared to EF, dapper is pretty lacking on the tooling and developer experience front. You’re on your own if there are changes to the database tables you’re querying. If you modify columns, you’ll have to find all of your queries that reference that table and update them to match the new table definition. This is one of the biggest maintainability headaches with dapper.
Change Tracking
Entity Framework
EF has built in change tracking. This means that any time you read out a model from the database and make changes, you can automatically save those changes right back to the database without any additional work. This does come with some performance overhead, but not a lot in most scenarios.
Dapper
There is no support for automated change tracking in dapper. Any updates to models will have to be manually written out in SQL and executed against the database.
Query Control/Performance
Entity Framework
With EF, you have very limited control over the queries being generated. The only way to control the queries is by restructuring linq statements to change the way the SQL is generated. By choosing EF you give up some control over the way the queries are structured, but you’ll save a lot of time not writing SQL. EF has also been known to be much slower than other options for querying and getting results back, although it has made a lot of strides in improving performance.
Dapper
One upside of dapper is that you have full control of the queries running against your database. The query performance is fully up to the developer. It’s easier to see when queries will have performance issues since the queries are defined up front, rather than hidden behind entity framework’s black box of query generation. There are certain situations that EF will not handle well, and you have little control to change it.
Being a micro-ORM, dapper is one of the most performant ways to run SQL statements and map the results back into C# models. So if performance is your biggest concern, dapper is a no-brainer.
Flexibility
Entity Framework
EF expects your data to be fairly well normalized and relies on foreign keys to determine object relationships in your C# models. If your database is not well normalized, EF will be tough to work with.
Dealing with stored procedures and raw SQL queries is also a pain when using entity framework. There is support for these scenarios, but it’s not as easy or out of the box as using dapper.
Dapper
Dapper is able to handle pretty much any database structure or scenario you throw at it. Denormalized tables? No problem. Missing foreign keys? No issues there. Running stored procedures? Great.
Which is best for your scenario?
Each situation will be different when deciding between these ORMs, so here are some questions I ask myself to help make a choice between EF and dapper.
Does my database have foreign keys?
If not, dapper is probably the way to go.
This is always my first question, and can make the decision clear right away. Entity framework will not play nicely with navigation properties if your database is missing foreign keys. While it would be best to get foreign keys added, it’s not always an option.
Is database performance a major concern?
If yes, dapper is a good fit.
While EF is catching up to dapper in performance, dapper still holds the lead. Check out this article for a performance comparison.
Am I doing lots of create and update operations?
If yes, entity framework may be preferred.
You’ll save a lot of headache by choosing entity framework in this scenario, since it will automatically track changes and generate the queries to save those changes without your intervention.
. . .
Wrap Up
There are lots of great features in both entity framework and dapper. The choice between the two will always be context dependent, but having knowledge about each ORM will give you confidence in the decision to use one or the other (or use both).