Data layer · Case study
MiniORM was my way of proving that a lightweight abstraction can keep SQL honest while removing the repetitive parts that slow a developer down.
Role
Designed & built end to end
Timeline
2024
Platform
.NET / ADO.NET
Status
Shipped
So much of a small app’s time disappears into repetitive mapping code, manual reader handling, and the ceremony around moving data from tables to objects. MiniORM concentrates that in one place — without replacing SQL.
Row mapping was too repetitive to keep honest
Every query needed the same object-building steps, which made the data layer noisy and easy to drift out of sync. The more database logic leaked into features, the harder it became to see what each screen actually needed.
The goal was never to hide SQL. It was to make the data layer feel predictable and small, so each query stayed explicit while the surrounding glue code got easier to read.
Keep the abstraction close to ADO.NET
I traded framework-level convenience for predictability: explicit mapping over reflection-heavy magic, a narrow public API so the common case stays short, and a structure simple enough to grow without turning into a dependency. Start with the query you already know how to write, pass it through a small helper that owns connection and mapping, and get typed objects back.
A smaller mental load at every call site
mapping noise
the repetitive parts moved into one place, so feature code scans cleanly
call sites
consumers focus on the query and the model instead of the plumbing
debug story
close enough to ADO.NET that stepping through it stays straightforward