`Deveel.Repository.Dapper` - Lightweight Dapper-Backed Repository Implementation

[tsutomi]

"Give teams using Dapper as their data-access strategy a first-party driver that maps Deveel Repository abstractions directly to raw SQL and stored procedures — without forcing them into a full ORM."

The Problem Today
Dapper is the most widely adopted micro-ORM in the .NET ecosystem: lightweight, fast, and SQL-first. Teams using it today must either hand-roll repository wrappers around every query (losing the framework's pluggable caching, validation, event emission, and health-check benefits) or adopt EF Core just to use the framework — a non-starter for SQL-optimization-conscious teams and legacy database migrations.

What We Are Building

• A Deveel.Repository.Dapper package built on Dapper and Microsoft.Data.SqlClient / Npgsql / generic DbConnection
• IRepository<TEntity, TKey> backed by convention-over-configuration SQL generation (or overridable per-operation SQL templates)
• Native stored procedure and batch-operation execution mapped to the batch and streaming APIs from v1.8
• Flexible entity-to-SQL mapping: table name, column mapping, key strategy configurable per entity
• Automatic IDbConnection lifecycle management from a registered DbDataSource or connection-string provider
• Full driver parity: filtering from IQueryFilter → parameterized WHERE clauses, pagination → OFFSET/FETCH, soft-delete filtering, and health checks

Benefits

• The most .NET-native ORM becomes a first-class Deveel Repository driver — no boilerplate wrappers, no vendor lock-in
• Teams keep their existing Dapper investment (raw SQL, existing procedures, performance-tuned queries) while gaining the full framework feature set
• The driver works against any ADO.NET provider: SQL Server, PostgreSQL, MySQL, SQLite — a single abstraction across heterogeneous databases
• A smooth migration path from hand-rolled Dapper repositories to a consistent, observable, and cache-aware pattern