What is an ORM, and what are the trade-offs of using one?
Quick Answer
An ORM (Object-Relational Mapper) maps database tables to objects so you work with classes and LINQ instead of SQL strings and manual mapping. Pros: less boilerplate, type safety, change tracking, migrations. Cons: it hides the SQL (so you can write inefficient queries without realising), the mapping abstraction leaks, and it adds a learning curve and a dependency.
An ORM maps your tables to classes so you query with LINQ and it generates the SQL and maps the results back. The upside is a huge reduction in repetitive data-access code, plus change tracking and migrations. The downside is that it hides the SQL, so it's easy to write something that loads a whole table when you meant to filter, and the object-to-relational mapping is a leaky abstraction that occasionally forces you to know exactly what it's doing. The pragmatic answer is EF Core for the bulk of the CRUD and Dapper or raw SQL for the few queries where performance really matters.
- Solves the “impedance mismatch” between rows/relations and objects/graphs.
- EF Core — full ORM: tracking, migrations, LINQ translation. Best for CRUD-heavy apps.
- Dapper — a micro-ORM: you write the SQL, it maps the results. Best when you want control and raw speed.
- ADO.NET — no mapping at all; maximum control, maximum boilerplate.
- Common approach: EF Core for the 90% CRUD, drop to Dapper or raw SQL for the hot reporting queries.