# Dapper.Repositories generates CRUD SQL from your POCO classes > MicroOrm.Dapper.Repositories is a C# library that builds CRUD statements for a POCO class from its metadata, with a generic SQL generator you can override. It covers the repetitive queries and leaves anything complicated to Dapper itself. **phnx47/dapper-repositories** — Generate SQL for CRUD operations based on your POCO classes for Dapper - Repository: https://github.com/phnx47/dapper-repositories - Website: https://www.learndapper.com/extensions/microorm-dapper-repositories - Stars: 705 · Forks: 205 - Language: C# - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/phnx47-dapper-repositories ## The problem is repetitive SQL, not a missing ORM The framing of this project is worth reading carefully, because it explains both what the library does and what it deliberately refuses to do. The documentation starts from Micro ORMs, describing them as simple libraries whose main goal is the fastest execution of your SQL statements in your data repository, and notes that for some of them you write your own SQL, which is the case for the most popular Micro ORM, Dapper. That is the gap. Dapper is fast precisely because it does not abstract the SQL away, and that is also why a Dapper codebase accumulates a lot of near-identical INSERT, UPDATE, DELETE and SELECT statements. This library sits on top of that rather than replacing it. The stated goal is helping with common, simple queries so you do not have to write repetitive SQL by hand, and the limitation is stated in the same paragraph: it does not try to cover every possible scenario, and for complex queries you should write SQL directly using Dapper. That framing is the reason to consider it at all, because it tells you the scope is narrow on purpose rather than by omission. ## A generic SQL generator driven by POCO metadata The mechanism is described at a technical level in the project documentation, and it is short enough to be worth reading in full. The library abstracts the generation of SQL for CRUD operations based on each C# POCO class metadata. The SQL Generator is a generic component that builds all CRUD sentences for a POCO class based on its definition, with the possibility to override the SQL generator and the way it builds each sentence. Two mechanisms are doing the work here, and both matter. The first is that the generator is generic, so a single implementation serves every entity type rather than each POCO needing its own handwritten statement set. The second is that it is overridable, and this is the part that decides whether the library is usable in your project. A generated statement that does not match your conventions, your column names, your schema or your parameter style is a problem you can only solve if there is a documented seam. The override point is that seam, and the documentation page on Learn Dapper is where the details of those extension points live. The repository layout matches a mature library rather than a script: src/ and tests/ at the top, a solution file named MicroOrm.Dapper.Repositories.sln, a Directory.Build.props for shared build settings, an .editorconfig, and CI running on the main branch. ## Where the generated SQL earns its keep The description does not enumerate the individual statements, so it is worth being careful here and staying with what is actually documented: the generator builds all CRUD sentences for a POCO class based on its definition. That means the four operations rather than a query language, and the practical value sits in the places where a Dapper codebase repeats itself most. An entity with twenty properties gets twenty parameters on every write, and those parameter lists are where hand written SQL rots, because adding a column means editing every statement that touches the table. A generator that reads the same class definition produces the parameter list for you, so adding a property to the POCO updates the SQL without a second edit. The same argument applies to reads, where the column list and the type mapping are derived from the class rather than maintained by hand. The other side of that coin is the one the project is honest about. Because the generator works from the class definition and its metadata, a table whose shape does not match its POCO, or which needs a join, an aggregate, a lock hint or a vendor specific clause, is a case the generator does not cover. Those statements still go through Dapper directly, which is a reasonable division, but it does mean a project ends up with two styles of data access. ## Getting the package and the version to pin The package is distributed on NuGet under the name MicroOrm.Dapper.Repositories, and the project documentation does not give a command line install step, so the route is the NuGet package page or the installation section of the Learn Dapper documentation. The version history is steady. v1.32.2 was released on 2026-07-25, v1.33.0 on 2026-08-02, and v1.34.0 on 2026-09-18, and the last push to the repository was on 2026-10-13. The repository is not archived, so the work is current. A steady minor version cadence on a library like this is a reasonable signal that the public surface keeps moving, which cuts both ways: it means fixes arrive, and it means a good integration test suite in your own project is worth having, since a minor bump can change the shape of the generated SQL. The library is licensed under the MIT license, which the project states covers all contents of the package, and the licence file is kept at the root of the repository. The project also notes that it was inspired by Diego García's Dapper.DataRepositories, which is worth knowing if you have come across that earlier project and found the SQL output style familiar. The sponsorship arrangements for Dapper Plus and Entity Framework Extensions are commercial relationships and do not change the MIT terms on the code itself. ## What the generated SQL will not do for you The limitations are not hidden, but they are also not enumerated, and that is the main thing a buyer should weigh. The project states plainly that it does not try to cover every possible scenario and points complex queries back to Dapper. What that means in practice is that the generated CRUD statements are the easy end of the problem space. Anything relational is outside the scope: multi table queries, aggregates, set operations, recursive queries, and any statement where the shape of the result does not match the shape of a single POCO. There is also a category of risk that has nothing to do with query complexity, which is schema drift. A generator that derives column lists from class properties will produce SQL that matches the class, not the database, so any column that exists in the table but not on the class, or any property that does not exist as a column, needs attention. Columns that should not participate in a write, identity columns that must be excluded from an UPDATE, and tables whose naming conventions differ from the property names are the places where the override mechanism has to be used. The documentation on Learn Dapper is where those extension points are described, and a team adopting this should read them before committing to it, because the override surface is the difference between a library that fits your schema and one that fights it. The alternative to consider is not a heavier ORM but a different approach altogether, which is to keep Dapper and accept the repetition, or to write the statements by hand once per aggregate and reuse them. That approach costs more typing up front and buys full control over the SQL, which is exactly what a high traffic or unusual schema tends to need. ## Conclusion Adopt MicroOrm.Dapper.Repositories if you are on Dapper, your entities are plain POCOs, and most of your queries are single table reads and writes that you would rather not type by hand. Do not adopt it as a general query builder or an ORM, since the project states it does not try to cover every scenario and sends complex work back to Dapper. Before you wire it into a data layer, check the SQL the generator produces against your database conventions, confirm that version 1.34.0 on NuGet matches the API your code expects, and read the override points in the documentation to see whether your schema needs column name mapping. ## FAQ ### What does MicroOrm.Dapper.Repositories do? It abstracts the generation of SQL for CRUD operations based on each C# POCO class metadata, using a generic SQL Generator component that builds all CRUD sentences for a class from its definition. The generator and the way it builds each sentence can both be overridden. ### Does Dapper.Repositories replace Dapper? No. It sits on top of Dapper and handles common, simple queries so you do not write repetitive SQL by hand. The project states it does not try to cover every possible scenario, and for complex queries you should write SQL directly using Dapper. ### How do I install MicroOrm.Dapper.Repositories? The package is published on NuGet as MicroOrm.Dapper.Repositories, and the project documentation points to the Learn Dapper documentation site for the full setup instructions rather than giving a command line install step. ### What licence is Dapper.Repositories released under? All contents of the package are licensed under the MIT license, with the licence file kept at the root of the repository. The project notes it was inspired by Diego García's Dapper.DataRepositories. ### How do I customise the SQL that Dapper.Repositories generates? The SQL Generator is a generic component, and the project documentation states that you can override the generator and the way it builds each sentence. The details of those extension points are described in the documentation on Learn Dapper. ## Sources - [License: MIT](https://github.com/phnx47/dapper-repositories/blob/main/LICENSE) - [phnx47/dapper-repositories on GitHub](https://github.com/phnx47/dapper-repositories) - [Project website](https://www.learndapper.com/extensions/microorm-dapper-repositories) - [README](https://github.com/phnx47/dapper-repositories/blob/main/README.md) - [Releases](https://github.com/phnx47/dapper-repositories/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/phnx47-dapper-repositories