Wie implementiert man das Unit Of Work Muster mit Dapper?

Stehen auf den Schultern der anderen hier.

In Anbetracht dieser Antwort ist oben in den meisten Google-Suchanfragen in Bezug auf "dapper" und "unit of work". Ich wollte meine Herangehensweise, die ich verwendet habe, zu große Wirkung, mehrere Male jetzt.

Mit einem ficitious (und sehr vereinfacht) Beispiel:

public interface IDbContext 
{
    IProductRepository Product { get; set; }

    void Commit();
}

public interface IUnitOfWork
{
    IDbTransaction Transaction { get; }

    void Commit();
}

public interface IProductRepository 
{
    Product Read(int id);
}

Hinweis, wie weder IDbContext oder IUnitOfWork IDisposable implementiert. Dies ist absichtlich getan, um zu vermeiden, eine leaky abstraction. Statt der Rückgriff auf Commit() zu kümmern, Aufräumen und Entsorgung.

Ein paar Punkte vor der Freigabe Implementierungen.

• IDbContext ist das repository, das Rückgrat.
• IUnitOfWork ist eine Kapselung von IDbTransactionund sorgt dafür, dass bei der Arbeit mit mehreren repositories, die Sie teilen sich eine einzige Datenbank-Kontext.

Umsetzung von IDbContext

public class DbContext : IDbContext
{
    private string connectionString;
    private IDbConnection connection;
    private IUnitOfWork unitOfWork;

    private IProductRepository product;

    public DbContext(string connectionString)
    {
        if (string.IsNullOrWhiteSpace(connectionString))
        {
            throw new ArgumentNullException("Connection string cannot be null");
        }

        this.connectionString = connectionString;
    }

    public IProductRepository Product =>
        product ?? (product = new ProductRepository(UnitOfWork.Transaction));

    private IDbConnection Connection
    {
        get
        {
            return connection ?? (connection = new SqlConnection(connectionString));
        }
    }

    private IUnitOfWork UnitOfWork
    {
        get
        {
            if (unitOfWork == null)
            {
                if (Connection != null && Connection.State != ConnectionState.Open)
                {
                    Connection.Open();
                }

                unitOfWork = new UnitOfWork(Connection);
            }

            return unitOfWork;
        }
    }

    public void Commit()
    {
        try
        {
            UnitOfWork.Commit();
            Connection?.Close();
            Connection?.Dispose();
        }
        finally
        {                
            Reset();                
        }
    }

    private void Reset()
    {
        connection = null;
        unitOfWork = null;
        product = null;
    }
}

Umsetzung von IUnitOfWork

public class UnitOfWork : IUnitOfWork
{
    private IDbTransaction transaction;

    public UnitOfWork(IDbConnection connection)
    {
        transaction = connection.BeginTransaction();
    }

    public IDbTransaction Transaction =>
        transaction;

    public void Commit()
    {
        try
        {
            Transaction.Commit();
        }
        catch
        {
            Transaction.Rollback();
            throw;
        }
        finally
        {
            Transaction?.Dispose();
            transaction = null;
        }
    }
}

Umsetzung von IProductRepository

public class ProductRepository : IProductRepository
{
    public ProductRepository(IDbTransaction transaction)
    {
        Transaction = transaction;
    }

    protected IDbConnection Connection =>
        Transaction.Connection;

    protected IDbTransaction Transaction { get; }

    public Product Read(int id)
    {
        return Connection.QuerySingleOrDefault<Product>("select * from dbo.Product where Id = @id", new { id }, transaction: Transaction);
    }
}

Zugriff auf die Datenbank, einfach instanziieren DbContext oder Spritzen mit dem IoC-container Ihrer Wahl (ich persönlich benutze den IoC-container von .NET Core).

var db = new DbContext("your connection string");

var product = db.Product.Read(1);
db.Commit();

Die explizite Notwendigkeit für Commit() für dieses einfache nur-lese-Betrieb scheint übertrieben, aber zahlt sich, wie das system wächst. Und anscheinend, bietet eine kleinere Leistung nach Sam Safran. Sie "können" auch weglassen db.Commit() auf einfache lese-Operationen, dies zu tun, obwohl Sie verlassen die Verbindung offen und legen Sie die Verantwortung für die Reinigung die Dinge auf den garbage collector. So dass dies nicht empfohlen.

Ich in der Regel bringen die DbContext in die Falte auf der service-Schicht, in der es arbeitet im Einklang mit anderen Diensten zu bilden, die "ServiceContext". Ich habe dann einen Verweis auf diese ServiceContext im eigentlichen MVC-Schicht. Als ein weiterer Punkt zu erwähnen, ist es empfehlenswert, verwenden async den ganzen Stapel, wenn Sie können. Es entfällt hier der Einfachheit halber.

InformationsquelleAutor der Antwort pimbrouwers