Dommel turns Dapper into a CRUD API over your POCOs

The API hangs off IDbConnection, so it fits wherever Dapper already is

Dommel provides a convenient API for CRUD operations using extension methods on the IDbConnection interface, and the SQL queries are generated based on your POCO entities. That placement is the design decision worth understanding before anything else. Because the methods are extension methods on a connection abstraction, they work with whatever connection object you already have, whether that is a raw DbConnection, a transaction wrapper or a connection handed to you by a pool, and they work inside the same code path as the hand written Dapper queries next to them. There is no separate unit of work, no session, no change tracker and no migration story. The repository topics list crud, dapper, micro-orm, query-builder and sql-expression, and that is an honest summary of the scope. It is a query generator that sits on top of Dapper rather than a replacement for it.

Dapper still does the execution and the object mapping

The README is explicit about the division of labour: Dapper is used for query execution and object mapping. Dommel decides what the SQL should say, and Dapper sends it and maps the rows back to your objects. That is a smaller claim than an ORM makes, and it has a practical upside. The mapping behaviour is the one you already rely on, so a column that does not map cleanly to a property behaves the same way it does for your existing Dapper calls rather than introducing a second convention. The topics list the project as a micro-orm, which tells you the intent. The trade is that you keep Dapper's explicitness. There is no change tracking, so a read-modify-write cycle is still your code to write, and no lazy loading, so a navigation property is a query you make yourself.

LINQ expressions are translated into SQL, with a boundary

Dommel also supports LINQ expressions which are being translated to SQL expressions, and this is the feature that makes it a query builder rather than only a CRUD helper. The repository topics carry sql-expression and query-builder for exactly this reason. The benefit is that a filtered list can be expressed in the same style as the rest of your .NET code without hand writing the WHERE clause, which is where the real value of a micro-ORM lives. The boundary is equally important, and it is the reason the readme lists the project as a micro-ORM rather than a full query builder. Expression translation covers what can be expressed, and complex joins, set operations and vendor specific SQL are not reliably expressible in a LINQ tree. A tool like this is best treated as the fast path for single table work, with hand written Dapper SQL still available and still necessary. If your queries are mostly multi table joins, this layer earns you little.

Name resolution is conventional, and every convention is an extension point

The third feature in the list is the one that decides whether Dommel works for your database at all. There are several extensibility points available to change the behavior of resolving table names, column names, the key property and POCO properties, and the documentation has a dedicated Extensibility section for the details. The default behaviour is inference: a class name maps to a table name, a property name maps to a column name, and a property is assumed to be the primary key unless you say otherwise. That inference is what makes the library pleasant with a conventionally named schema, and it is also its first failure mode. A table called T_User, a schema prefix, a column stored as user_id where the property is UserId, or a view instead of a table will all produce a query that compiles perfectly and then fails at the database. The extensibility points exist precisely so that these cases can be handled without renaming anything, so the order of work for an adopter is to check the naming first and configure the exceptions second.

Installing it is one package reference in either of two tools

Dommel is available on NuGet, and the README gives two routes. With the .NET CLI:

dotnet add package Dommel

With the NuGet Package Manager in a Visual Studio package manager console:

Install-Package Dommel

The full documentation is not in the repository, it lives at Learn Dapper on the learndapper.com site, under the extensions section for Dommel, and that site is also the listed homepage. The repository itself is small, with a Dommel.sln solution, src/ and test/ directories, a Directory.Build.props for shared build properties, a build.ps1 script, an AGENTS.md and a CLAUDE.md, and a NuGet.Config for package sources. The build pipeline is a CI workflow with a badge in the readme, and the package is published with a preview version badge alongside the stable listing. If you take one thing from the packaging, take the two-command install options: there is nothing else to configure, because Dommel is a library rather than something with a runtime host of its own.

The project is sponsored by commercial extensions to Dapper

The sponsorship section is worth reading for a different reason than the logos. Dapper Plus and Entity Framework Extensions are described as major sponsors and are proud to contribute to the development of Dommel. That tells you something about the ecosystem this library sits in, and it tells you something about its position. Dommel is the free, open, single table CRUD layer that a project can adopt without a commercial licence, while the sponsors sell the heavier tools for bulk insert and for the Entity Framework side of the market. For an adopter, the practical reading is that Dommel is deliberately small and that the features it does not have, bulk operations in particular, are exactly the features its sponsors sell separately. If bulk insert matters to your workload, that is a decision to make consciously rather than to discover later. The licence itself is MIT, held in the LICENSE file at the top of the repository, so using Dommel in a commercial product carries no copyleft obligation, and the sponsorship arrangement does not change the terms under which you use the code.

The release history is steady, with a long gap in the middle

The maintenance picture is calm rather than busy. The repository is not archived, and the last push was on 2026-06-24. The recent tags are v3.5.2 on 2026-05-15, v3.5.1 on 2025-12-10 and v3.5.0 on 2025-11-14, which is a sensible minor version cadence with patch releases inside each minor. The 3.x line signals that the API has been through enough change to have settled, and the version numbers themselves carry no experimental suffix, unlike many .NET libraries. What the history also shows is a project that is not chasing a feature treadmill, which for a library whose job is to stay out of the way is arguably the right pace. A dependency like this is the kind of thing that sits in a csproj for years, so the more relevant question for a new adopter is not how often it ships but whether it fits your naming conventions, since that is what you will be living with.

Where Dommel is the wrong tool

Three cases argue against it. The first is a data model that does not follow the conventions the inference relies on. A schema with prefixes, plural table names, a non standard primary key name or a legacy naming scheme will produce queries that fail, and while the extensibility points can fix that, they add a mapping layer that has to be maintained for every entity, at which point hand written SQL in Dapper is the honest answer. The second is a workload dominated by joins, aggregates and set operations. The LINQ to SQL translation covers the simple cases, and the moment your real queries are multi table, you are back to writing SQL, and now you have two styles of data access in the same project. The third is a team that wants change tracking, identity map behaviour or lazy loading, because a micro-ORM deliberately does not provide those, and a micro-ORM is not the place to find them. The alternative worth naming is Dapper itself with explicit SQL, which gives you full control over the statement and no inference to fight, at the cost of writing every CRUD statement by hand. For a project with a handful of tables and simple screens, that cost is often smaller than the cost of a wrong guess about how a table is named.

Editorial conclusion

Adopt Dommel when your application already uses Dapper and you want CRUD calls generated from POCO shape rather than a second data access stack, and write the SQL by hand when a query needs joins, unions or anything the expression translator cannot express. Verify first that your table and column names follow the conventions Dommel infers, because a mapped view or a prefixed schema will produce a query that compiles and then fails, and read the extensibility section before assuming you must rename anything in the database.

Frequently asked questions

Official sources

1. henkmollema/Dommel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases