Insert, update and delete thousands of records without writing a line of SQL.

Why DapperMany

Dapper already handles line-by-line object-relational mapping very well. What's missing is a performant way to move many records at once — including trees of related objects — without falling back to hand-written SQL or losing control over database-generated Ids.

Installation

Install the core package and the provider for the database you use. When the assembly loads, the provider registers itself — no extra configuration needed.

dotnet add package DapperMany
dotnet add package DapperMany.SqlServerCopy

Quickstart

Map your classes with attributes and call the extension operations directly on the connection.

[Table("Orders")]
public class Order
{
    [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int Id { get; set; }

    public string Customer { get; set; }
    public DateTime OrderDate { get; set; }

    [HasMany(foreignKey: nameof(OrderItem.OrderId))]
    public List<OrderItem> Items { get; set; }
}

[Table("OrderItems")]
public class OrderItem
{
    [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int Id { get; set; }

    public int OrderId { get; set; }
    public string Product { get; set; }
}Copy

await connection.InsertManyAsync(orders);    // parent + children, FK resolved automatically
await connection.UpdateManyAsync(partialOrders);  // object with just [Key] + fields to update
await connection.DeleteManyAsync(orderIds);Copy

Entity attributes

DapperMany reuses System.ComponentModel.DataAnnotations.Schema whenever possible — anyone who already knows EF Core will recognize [Table], [Key] and [DatabaseGenerated] right away. Relationships are declared with [HasMany] (1:N) and [HasOne] (1:1).

[Table("Orders")]
public class Order
{
    [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    public int Id { get; set; }

    public string Customer { get; set; }
    public DateTime OrderDate { get; set; }

    [HasMany(foreignKey: nameof(OrderItem.OrderId))]
    public List<OrderItem> Items { get; set; }

    // 1:1 relationship — single reference property
    [HasOne(foreignKey: nameof(OrderDetail.OrderId))]
    public OrderDetail Detail { get; set; }
}Copy

Public API

Five extension methods over IDbConnection — nothing else is exposed to the consumer.

public static class DbConnectionExtensions
{
    Task InsertManyAsync<T>(this IDbConnection cn, IEnumerable<T> entities, IDbTransaction? tx = null);
    Task InsertManyAsync<T>(this IDbConnection cn, IEnumerable<T> entities, IDbTransaction? tx = null);
    Task UpdateManyAsync<T>(this IDbConnection cn, IEnumerable<T> entities, IDbTransaction? tx = null);
    Task DeleteManyAsync<T>(this IDbConnection cn, IEnumerable<T> entities, IDbTransaction? tx = null);
    Task DeleteManyAsync<T>(this IDbConnection cn, IEnumerable<object> keys, IDbTransaction? tx = null);
}Copy

InsertMany / InsertManyGraph

InsertManyAsync performs bulk inserts for flat collections or entity graphs with automatic relationship detection. When relationships are detected, parent IDs are populated back into each entity and FK values are propagated to children.

1. Inserts the parent records — the strategy depends on the provider (see Providers).
2. Populates the generated Id back into each parent entity via a compiled setter.
3. For each marked relationship, checks whether there's data: a non-null, non-empty collection ([HasMany]) or a non-null reference ([HasOne]) — otherwise it skips without building a batch.
4. Propagates the parent's FK to the children and groups them by type.
5. Executes native bulk copy for the grouped children, when supported by the provider.
6. Recurses for nested relationships (grandchildren), if any.

Edge cases

Null or empty children: inserts only the parent.

var order = new Order { DocumentNumber = "ORD-NULL", Items = null };
await connection.InsertManyAsync(new[] { order }); // Inserts only the parentCopy

[HasOne] (1:1) is treated as a single child — same FK propagation, same bulk flow.

var order = new Order { DocumentNumber = "ORD-DET", Detail = new OrderDetail { /* ... */ } };
await connection.InsertManyAsync(new[] { order }); // Inserts parent + detail (1:1)Copy

UpdateMany

Takes a partial object: [Key] is required, used for the JOIN/MERGE, plus only the fields to update. The SET clause is generated dynamically from the properties present on the type — no manual column list.

Mechanism: staging table (bulk copy of the partial object) followed by UPDATE ... FROM (SQL Server/Postgres) or UPDATE ... JOIN (MySQL).

DeleteMany

Accepts a list of full entities or a list of keys (IEnumerable<object> keys).

await connection.DeleteManyAsync(orderIds);Copy

Transactions

Every bulk operation is required to run inside a transaction tied to the IDbConnection.

using var tx = connection.BeginTransaction();
await connection.InsertManyAsync(orders, tx);
tx.Commit();Copy

The transaction spans every phase of the operation — inserting/updating/deleting parents, populating FKs, bulk copying children and any identity reads. No operation touches the database outside that scope. Isolation in v1: the provider's default, typically ReadCommitted.

Providers

Each database has its own package and a different strategy for bulk copy and generated-Id retrieval.

Provider auto-registration

The core doesn't know any concrete driver. Each provider package registers itself when loaded, via [ModuleInitializer]:

internal static class SqlServerModuleInitializer
{
    [ModuleInitializer]
    public static void Initialize() =>
        ProviderRegistry.Register("Microsoft.Data.SqlClient.SqlConnection",
            new ProviderModule(new SqlServerDialect(), new SqlServerBulkCopyStrategy(), new SqlServerIdentityStrategy()));
}Copy

Cache & thread-safety

A cross-cutting foundation used by every operation — no attribute or property access repeats reflection at runtime.

EntityMetadata is immutable once built — concurrent reads need no locking. Connections (SqlConnection, NpgsqlConnection, MySqlConnection) aren't thread-safe for simultaneous use on the same instance, the same premise as plain Dapper.

Logging (Debug only)

In Debug builds, bulk operations emit diagnostics via Debug.WriteLine(), measured with a Stopwatch. In Release, those messages don't exist — everything sits behind #if DEBUG.

[DAPPERMANY] BulkInsert Order (SqlServer): affected=10, elapsed=45msCopy

For graph inserts, both the parent phase and the children phase are logged, with one aggregated total log at the end. This doesn't replace observability integrations like OpenTelemetry, which may be added in the future.

Implementation roadmap

1. Foundation: EntityMapper + AccessorFactory + EntityMetadata, with isolated concurrency tests.
2. Docker environment with the three databases and initial schema.
3. DapperMany (core) + DapperMany.SqlServer: a simple InsertManyAsync, validated with Testcontainers.
4. Samples project: an InsertMany scenario against SQL Server via local Docker.
5. InsertManyAsync on SQL Server — one relationship level first, recursion after.
6. UpdateManyAsync / DeleteManyAsync on SQL Server, with matching scenarios in samples.
7. Extract ISqlDialect / IBulkCopyStrategy / IIdentityRetrievalStrategy as formal interfaces.
8. DapperMany.Postgres + scenarios in samples.
9. DapperMany.MySql + scenarios in samples.
10. Benchmarks with BenchmarkDotNet comparing against row-by-row insert, per provider.
11. Documentation and package publishing on NuGet.

Out of scope (v1)

• Automatic dirty-tracking for UpdateMany from a full entity.
• Truly bulk parent inserts (multi-VALUES + OUTPUT) for high volume on the parent side too.
• Automatic cascading DeleteMany via [HasMany].
• Partial RETURNING/OUTPUT (column subset) to reduce traffic on wide updates.
• Additional providers (SQLite, Oracle) as independent packages.