Home

Dapper.Cqrs

Code in this repository and NuGet package is CQRS (Command Query Responsibility Segragation) database data access and manipulation principle, implemented using Dapper MicroORM. It is built to ease database data manipulations for development, separating Queries from Commands, allowing to use it as the only approach or together with other ORMs as supporting.

Library uses Microsoft.Extensions.Logging to provide extensive logging on internal processes (depending on logging level) and can provide valuable information during debugging application.

As Dapper uses "magic strings" for database queries, package is built in a way it exposes these magic strings for testing against database engine (and defined structures).

Code is separated into (at least) two assemblies (packages):

• Abstractions
• Database-specific implementation(s)

Abstractions

Provide common interfaces and base functionalities suitable for all database engines. This package does not demand specific database client as dependency. It contains IQuery and ICommand interfaces as well as internal interfaces and implementation to employ Unit-of-Work database connection handling.

Database specific

(Currently only MS SQL)

Classes and functionalities to work with database engine, handling its specific connection by opening, closing and transaction handling transparently for application which is using it.

Is it better than Entity Framework?

As with everything - yes and no. Using Dapper and similar in projects are usually tied to need for solid database data retrieval performance or getting data from very complex queries.

When using Entity Framework you are rarely concerned about SQL syntax and what magic is hidden behind your LINQ statements. It works perfectly for simple solutions and would be recommended approach.

But as soon as database becomes more complex and required data retrieval involves many objects - not following generated SQL behind LINQ can lead to considerable performance problems (N+1, Cartesian product). Then different non-standard side approaches are implemented (Stored Procedures, Views, Custom solutions - ADO.NET or using some MicroORM as fallback for such situations).

So using Dapper will make you write SQL statements and do more boilerplate coding, but it increases control over how and when data is read and write to database. This project just wraps Dapper into CQRS approach and allows to get all project SQL statements in "magic strings" easily located by C# code (e.g. for automated validation).