Dapper vs Entity Framework (EF6 or EF Core)

I prefer Dapper when reading data and Dapper Plus when saving data over EF Core. The combination of both libraries makes it perfect and gives me the best flexibility and performance.

Dapper gives me 100% control over how I select my data. It often happens that some SELECT statements are complex with multiple JOIN, GROUP BY, WHERE clauses, so writing my own SQL makes perfect sense to ensure the statement is optimized. When I select data, I can choose all information in one database roundtrip and make sure only the information I need is selected.

Dapper Plus ensures that my data is inserted, updated, or deleted the fastest way possible and doesn't force me to create those SQL statements. Saving data is usually very simple, so I don't want to bother writing those statements for every entity type I could have to save. In case I need to customize my saves, Dapper Plus gives me all the options I need without worrying about writing my SQL.

It's a little bit contradicting as I want 100% control of the SQL when reading data and no control when saving, but at the same time:

• When reading data, 95% of my code requires writing custom SQL
• When saving data, 95% of my code doesn't require any custom SQL

Sure Dapper Plus is not free, nor is my time for writing and testing all SQL that will save data in the Database.

Another important note:

• I mostly create personal projects such as ZZZ Code AI
• I don't have to handle a team. Only a few developers touch these projects with me

Yes, you can use Dapper and EF Core in the same project, but keep in mind that EF Core is complex, and Dapper is very simple to use, which makes a huge difference:

• If you already use EF Core, you can easily introduce Dapper to map results to entities for some special scenarios.
• If you already use Dapper, you should not introduce EF Core as it will make the project more complex.

Dapper is generally more performant than Entity Framework Core. As a micro-ORM, Dapper has less overhead and can quickly execute database operations. However, the difference in performance may not be significant for small to medium-sized applications or in scenarios where advanced features of EF Core are not heavily used. As always, the best choice depends on the specific requirements and constraints of your project.

Even if Dapper is the most performant, you might not notice the difference in most cases.

Dapper is easier to learn. As a micro-ORM, it has fewer features and a more straightforward API, resulting in a rapid learning curve. However, Dapper also requires developers to write raw SQL queries, which might be an additional thing to learn if you are unfamiliar with SQL.

On the other hand, EF Core is harder to learn but provides many advanced features and abstractions. On the plus side, you don't have to learn SQL, which can make learning easier for people with only a little SQL knowledge.

Both are easy to use when you are familiar with the ORM.

When starting, Dapper will be easier to use than EF Core as you can quickly understand the API.

However, EF Core might be considered easiest to use for those who prefer to work with LINQ and higher-level abstractions.

• Performance: Dapper is typically more performant than EF Core due to its lightweight nature and lack of overhead.
• Control over SQL Queries: With Dapper, you have full control over your SQL queries, which can lead to more optimized database operations.
• Simplicity: Dapper's simple and straightforward design makes it easier to learn and use, especially for developers already comfortable with SQL.
• Efficient Data Reader Mapping: Dapper enables efficient mapping from a .NET data reader to a specific object model.
• Flexibility with Stored Procedures: Dapper works seamlessly with stored procedures, unlike EF Core which can impose certain conventions.

• Performance: Dapper has a reputation for being one of the fastest micro-ORMs available for .NET. It provides significant performance gains over Entity Framework, especially when large amounts of data are queried.
• Flexibility: Dapper gives developers more control over their SQL queries, which can be a substantial advantage when you need to optimize certain queries or use more advanced SQL features that aren't supported by higher-level ORMs.
• Ease of Use: Despite providing lower-level access to your database, Dapper is still very easy to use and doesn't require a steep learning curve.
• Lightweight: Dapper is a micro-ORM and is considerably less resource-intensive than more feature-rich ORMs like Entity Framework. It's a great choice for applications where performance is critical.
• Simplicity: Dapper's simplicity can be seen in its API design, making it easy to understand and implement in projects.
• Integration with Stored Procedures: Dapper works seamlessly with stored procedures and doesn't impose any of its conventions, unlike Entity Framework. It can map the results from a stored procedure to a strongly typed model or a dynamic object.
• Batch Queries and Transactions: Dapper allows you to execute batch queries to enable more efficient data operations easily.
• No Tracking of Database Objects: Dapper doesn't track database objects, which simplifies coding for developers who prefer to manage the database state manually.
• Efficient Data Reader Mapping: Dapper allows for efficient mapping of a .NET data reader to a specified object model.

• Lack of Database Abstraction: Dapper provides less abstraction from the database compared to Entity Framework. Developers have to write raw SQL queries, which might not be ideal in scenarios where you'd prefer database-agnostic code.
• No Change Tracking: Unlike Entity Framework, Dapper does not support change tracking. That means you'll have to manage updates to your entities manually and write explicit update statements.
• Less Features: As a micro-ORM, Dapper is not as feature-rich as Entity Framework. It doesn't provide out-of-the-box features like lazy loading, change tracking, migrations, etc.
• No LINQ Support for Queries: It does not support LINQ to build SQL queries. That can be a disadvantage if you prefer LINQ's strong typing over writing SQL strings.
• More SQL Knowledge Required: Given that you'll be writing raw SQL queries, your team will need to be proficient in SQL, including understanding how to avoid SQL Injection attacks.
• Database Schema Updates: Unlike Entity Framework, which can update the database schema through migrations, Dapper lacks this feature. That could be a disadvantage when business logic changes require database schema changes.
• Lack of a Full Query Generator: Dapper does not have a full query generator, which could lead to writing more SQL for CRUD operations compared to Entity Framework.

• Fully Featured ORM: EF Core provides a rich set of features such as lazy loading, change tracking, migrations, and more.
• Database Abstraction: EF Core abstracts the database system, allowing you to switch between different databases with minimal code changes.
• Code First Development: EF Core supports code first approach, where you define your database structure using C# classes.
• Migrations: EF Core includes support for data migrations, allowing for database schema changes directly from the code.
• LINQ Support: With EF Core, you can use Language Integrated Query (LINQ) to build queries in C#, leading to more maintainable and readable code.
• Change Tracking: EF Core automatically tracks changes made to your entities and can update the database accordingly, eliminating the need for manual update statements.

• Database Agnostic: EF Core is database-agnostic, which means you can switch between different databases (like SQL Server, MySQL, SQLite, etc.) without changing much of your code.
• Fully Featured ORM: As a fully featured ORM, EF Core provides out-of-the-box support for complex operations like lazy loading, change tracking, transactions, migrations, and identity management.
• LINQ Support: EF Core supports Language Integrated Query (LINQ), allowing developers to write queries in C# instead of SQL, which results in more readable and maintainable code.
• Model-First Development: EF Core supports model-first development, where you define your database structure using C# classes. That can help keep your database structure in sync with your code.
• Change Tracking: EF Core automatically tracks changes made to your entities and can update the database accordingly, eliminating the need for explicit update statements.
• Data Migration: EF Core includes robust support for migrations, allowing developers to handle database schema changes directly from the code.
• Rich Querying Capabilities: EF Core supports complex querying, including filtering, sorting, grouping, joining, and eager loading, without needing to write complex SQL queries.
• Concurrency Control: EF Core has built-in support for optimistic concurrency control, which helps resolve conflicts when multiple users update the same data simultaneously.
• Unit Testing: EF Core makes it easier to write unit tests for your database code. You can create an in-memory database for your unit tests to interact with, ensuring tests run quickly without impacting your real database.

• Performance: EF Core can be slower than Dapper, especially when dealing with complex queries or large amounts of data due to its overhead of features and abstractions.
• Learning Curve: EF Core, being a fully featured ORM, is complex and has a steeper learning curve compared to Dapper. Understanding and effectively using all its features requires time and experience.
• Overhead: The abstraction and additional features of EF Core come with a performance cost. The overhead can lead to slower response times compared to Dapper, which is more lightweight and faster.
• Less Control Over SQL Generation: EF Core generates SQL queries automatically, which can be an issue if you need fine-tuned control over your SQL queries for optimization purposes.
• Database Provider Limitations: Although EF Core is database agnostic, not all features are supported equally by all database providers. Some features might work well with one database but not with others.
• Lazy Loading Pitfalls: While EF Core supports lazy loading, it can lead to performance issues if not used correctly. Unintended lazy loading can result in multiple round trips to the database, slowing down your application.
• Memory Usage: Due to its rich feature set and abstractions, EF Core can use more memory than micro ORMs like Dapper.
• Bulk Operations: EF Core is not optimized for bulk operations. Tasks like inserting or updating large amounts of data can be slow and resource-intensive compared to Dapper or other libraries designed for such tasks.