Pitfalls of relational DB access in .NET: rethinking micro-ORMs
summary
Claims that async everywhere helps are false: mostly-completed async calls (OpenAsync, ReadAsync, NextResultAsync) waste allocations so only ExecuteReader needs true async because connection pooling makes OpenAsync usually complete. Benchmarks show Dapper ~20% slower than the fastest micro-ORM and EF is orders of magnitude slower on cold starts. A two-stage fast disconnect (return DTOs, disconnect, then materialize POCOs) improves server efficiency. Memory trick: implement GTO as struct to shrink per-row footprint from ~32 bytes to 8 bytes. Tiny ORM fits ~700 lines and applies these optimizations.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 2:08About me
- 2:45Agenda
- 3:23Myth AtoNET
- 7:55Summary
- 8:57Method 1 Database connections must be there
- 11:11Method 2 You must have Pocus
- 16:17Method 3 Easy to use
- 25:13Method 4 Overhead
- 28:06Method 5 Multiple approaches
- 28:43One stage approach
- 29:51Two stage approach
- 30:43Comparison
- 35:38Giving it back
- 38:17Comparing microORMs
- 39:35Visualizing microORMs
- 41:42Improving iteration performance
- 49:03Bonus myths
- 51:00Asterix support
- 52:15Hybrid solution
related talks
45m.NET: SQL vs ORM - Will Dapper Resolve the Age-Old Debate?
54mBetter Object Mapping in .NET with Dapper
01h 05mAdvanced Weapons and Tactics
23mI Would Never Use an ORM
01h 01mEntity Framework Core Unchained Getting the Best Performance from Your ORM
01h 04mCommon mistakes in EF Core
01h 05mCommon mistakes in EF Core
01h 04mCommon mistakes in EF Core