ORM batch boundaries that look innocent
Published January 2025 · Stack Ridge team
During a data-access audit, a team insisted their cart update loop issued one round trip because Entity Framework “batches automatically.” Profiler traces told a different story: one SELECT per line item for inventory checks, then a single batched UPDATE for quantities.
Where the boundary hides
Lazy loading inside a foreach is invisible in unit tests that mock the context. Only integration tests—or SQL capture at the service boundary—show the fan-out.
Practical capture
We enable statement logging at the session level for the API user, run one realistic checkout payload, and annotate the trace with call stack links from Application Insights. Developers see which repository method triggered which statement.
Fix pattern
Project needed quantities in one query with WHERE sku IN (...), attach results to memory, then persist. Not exotic—just disciplined loading at the start of the transaction.