I have spent nearly thirty years building software on the Microsoft stack and have worked with .NET since its early days. For much of that time, my preferred way to talk to SQL Server has been Dapper and parameterized T-SQL. EF Core has given me plenty of reasons to reconsider over the years, but I still prefer to write the queries myself.

A large part of my career has been spent working directly in SQL Server. Writing a query is part of the work I enjoy. I want to decide which columns come back, how the tables join, and where the filtering happens. When something runs slowly, I want to examine the statement and its execution plan, then work out what needs to change.

Dapper handles a useful portion of that job: passing parameters, executing commands, and mapping returned rows to objects. It originated at Stack Overflow, and its relatively narrow scope suits me. I can keep writing SQL without repeatedly writing the code that reads each column from a data reader.

Performance matters, but it is not enough to settle this choice. A lightweight mapper cannot rescue a query that reads far too much data or makes hundreds of unnecessary database trips. Microsoft's EF Core performance guidance makes the same practical point: measure the application and find the bottleneck. A benchmark comparing mapper overhead tells you something useful, but it does not tell you how your application will behave.

My preference comes with work attached. With core Dapper, I am responsible for things a fuller framework can help manage:

• I write and maintain the SQL for reads, inserts, updates, and deletes. Changing an object in memory does not cause Dapper to save it.
• I pass values as parameters and choose appropriate parameter types. Dapper supports parameterization; it does not make a SQL string built by concatenating user input safe.
• I manage schema changes separately and keep the queries and their result mappings compatible with those changes.

I am comfortable taking that on. Another team might reasonably decide that LINQ, change tracking, and migrations save enough work to make EF Core the better choice. Those features address real development needs, including plenty that handwritten SQL does not make easier.

EF Core also allows handwritten SQL, so using it does not mean giving up that option. My preference is to start with SQL throughout the data-access layer. For the applications I build, Dapper gives me the mapping help I want without adding a model and tracking system I would then need to decide how much to use.

The age of the databases I work with also shapes that preference. This year I rewrote a web application originally built in 2013 and moved it to .NET 10. The production database did not need to change. The application was being replaced, but the schema was still doing its job.

EF Core could work with that arrangement too. It supports building a model from an existing database; adopting it would not inherently require redesigning the schema. What the rewrite reinforced for me was how comfortable I am treating the database as something maintained independently of the application in front of it.

That is why I still choose Dapper. I already expect to spend time in SQL, reviewing queries and understanding what the database is doing. Dapper takes care of enough repetitive work to be useful and leaves the part I want to work on directly in my hands.