C#•9mo ago

Dapper - Unit of work between 2 repositories

I need to keep a common transaction between 2 repositories, but I'm not sure who will be responsible for rolling it back in case of failure.
Those 2 repositories do share connection and transaction via parent, but one of them has to commit the transaction.
How do people usually go about this?

Do I make it so that the service is responsible for coordinating the repositories? I'm too new but this sounds wrong because a transaction commit/rollback is the responsibility of the database layer.
Do I call one repository method through another? This would mean injecting a repository, and I read that it's bad practice.

Sorry, I'm new to Dapper and Unit of Work as a pattern.

taner.•4/9/25, 3:13 PM

When u have an service class then u usually commit all transactions after everything is done

taner.•4/9/25, 3:13 PM

Can u share some code or give more details?

ThanacioOP•4/9/25, 3:17 PM

I can't because it's proprietary but I can approximate it.

Basically, so far in the codebase, the unit of work is implemented like that (code not mine):

public async Task<int> CreateOrderAsync()
{
// UseTransaction begins the transaction that will get shared
    UseTransaction(_connection.BeginTransaction());

    try
    {
        // dapper stuff

        foreach (var item in items)
        {
            // do stuff
        }

// transaction gets commited at the end
        _transaction.Commit();
        return orderId;
    }
    catch
    {
        _transaction.Rollback();
        throw;
    }
}

public async Task<int> CreateOrderAsync()
{
// UseTransaction begins the transaction that will get shared
    UseTransaction(_connection.BeginTransaction());

    try
    {
        // dapper stuff

        foreach (var item in items)
        {
            // do stuff
        }

// transaction gets commited at the end
        _transaction.Commit();
        return orderId;
    }
    catch
    {
        _transaction.Rollback();
        throw;
    }
}

ThanacioOP•4/9/25, 3:17 PM

This is taken from the Dapper Repository

ThanacioOP•4/9/25, 3:18 PM

I was wondering if lifting the Commit/Rollback responsibility to the service layer is a good/bad practice for it

ThanacioOP•4/9/25, 3:18 PM

because right now the only place in our code responsible for commiting the ongoing transaction lives in repository methodss

taner.•4/9/25, 3:19 PM

I guess Unit of Work is what u r looking for

ThanacioOP•4/9/25, 3:19 PM

yes!

ThanacioOP•4/9/25, 3:20 PM

ohhh I think I know where you're getting at

ThanacioOP•4/9/25, 3:20 PM

making an intermediate class called UnitOfWork

ThanacioOP•4/9/25, 3:20 PM

injecting it, then use it

ThanacioOP•4/9/25, 3:21 PM

I think there is one in the codebase

taner.•4/9/25, 3:21 PM

Yeah this class injects normally the db context

taner.•4/9/25, 3:21 PM

Where u commit ur changes etc

ThanacioOP•4/9/25, 3:21 PM

and is it used by the service?

taner.•4/9/25, 3:21 PM

Yeah

ThanacioOP•4/9/25, 3:21 PM

you're a lifesaver dude

ThanacioOP•4/9/25, 3:22 PM

literally

ThanacioOP•4/9/25, 3:22 PM

I'll keep you posted when I work it out

ThanacioOP•4/9/25, 3:22 PM

brb

taner.•4/9/25, 3:22 PM

Yeah do it

ThanacioOP•4/9/25, 4:17 PM

alright, it's done!

ThanacioOP•4/9/25, 4:17 PM

I even separated a concern to a new service

ThanacioOP•4/9/25, 4:17 PM

thank you again for your help! probably saved my life

taner.•4/9/25, 4:58 PM

u r welcome

ThanacioOP•4/14/25, 3:10 PM

fwiw I think I had the right idea but ended up messing the execution and that cost me a job offer, but oh well

public async Task<int> CreateOrderAsync() { // UseTransaction begins the transaction that will get shared UseTransaction(_connection.BeginTransaction()); try { // dapper stuff foreach (var item in items) { // do stuff } // transaction gets commited at the end _transaction.Commit(); return orderId; } catch { _transaction.Rollback(); throw; } }