Depo ve İş Birimi Arasındaki İlişki

Bir depo uygulayacağım ve deponun tüketicisi birkaç işlem yapabileceğinden UOW modelini kullanmak istiyorum ve aynı anda taahhüt etmek istiyorum.

Konuyla ilgili birkaç makaleyi okuduktan sonra, hala başka bir şekilde yapıldığı makaleye bağlı olarak, bu iki öğeyi nasıl ilişkilendireceğim.

Bazen UOW depodaki dahili bir şeydir:

public class Repository
{
    UnitOfWork _uow;

    public Repository()
    {
       _uow = IoC.Get<UnitOfWork>();
    }

    public void Save(Entity e)
    {
        _uow.Track(e);
    }

    public void SubmittChanges()
    {
        SaveInStorage(_uow.GetChanges());
    }
}

Ve bazen dışsaldır:

public class Repository
{
    public void Save(Entity e, UnitOfWork uow)
    {
        uow.Track(e);
    }

    public void SubmittChanges(UnitOfWork uow)
    {
        SaveInStorage(uow.GetChanges());
    }
}

Diğer zamanlarda, Depola referans veren UOW

public class UnitOfWork
{
    Repository _repository;

    public UnitOfWork(Repository repository)
    {
       _repository = repository;
    }

    public void Save(Entity e)
    {
        this.Track(e);
    }

    public void SubmittChanges()
    {
       _repository.Save(this.GetChanges());
    }
}

Bu iki unsur nasıl ilişkilidir? UOW, değiştirilmesi gereken öğeleri izler ve depo, bu değişiklikleri devam ettirmek için mantığı içerir, ancak ... kim kimi çağırır? Sonuncusu daha anlamlı mı?

Ayrıca, bağlantıyı kim yönetir? Havuzda birkaç işlem yapılması gerekiyorsa, aynı bağlantıyı kullanmak ve hatta işlemin daha sağlam olduğunu düşünüyorum, bu yüzden belki de bağlantı nesnesini UOW'un içine koyun ve bu da havuzun içine de mantıklı geliyor.

Şerefe

Re: "UOW değiştirilmesi gereken öğeleri izler ve depo bu değişiklikleri devam ettirmek için mantığı içerir, ama ... kim kimi çağırır?"

Bu sınıfların temel sorumluluklarını anlıyorsunuz. Okuduğunuz makalelerin her birinin bunları farklı şekillerde birbirine bağladığını söylüyorsunuz. Bu "kim kimi arar" hakkındaki kararın size bağlı olduğu anlamına gelir.

Uyum , Dekuplaj , Yeniden Kullanılabilirlik , Birim-Test Edilebilirlik gibi iyi yazılım tasarımının temel prensipleri tarafından yönlendirilirken sorunu 'katmanlar' olarak çizmeye çalışacağım .

Alıntı Eric Evans Domain Driven Design, (2004) Addison Wesley, pg 69 :

[Katmanlı Mimariler] 'in temel prensibi, bir katmanın herhangi bir elemanının sadece aynı katmanda bulunan diğer elemanlara veya katmanın "altındaki" elemanlara bağlı olmasıdır.

Kanımca, hem UOW hem de Repo, net, bağımsız, sorumlulukları olan iki çok farklı sınıftır. Başlangıç ​​olarak, diğerini çağırmam da olmazdı.

Ben gerçekten 'repo ne zaman ve ne almak' ve işlemi kaydetmek için 'ne zaman' bilen bazı üçüncü istemci sınıfı (yani ya bir controllerveya service class) gerekir. Bu istemci mimarisi (şimdiye olabilir nispeten yüksek oturur biliyorum daha sınıfları hakkında) ve ikisi arasındaki bazı orkestrasyon yapabilirsiniz.

--------------------------------

         [Client]
           /   \
----------/---- \---------------
         /       \
        V         V
[Unit Of Work]  [Repo]


--------------------------------

Yöntemler en yaygın olarak UOW arayüzüne (normalde bir fabrika aracılığıyla inşa edilir) verilir.

Genellikle UOW arabirimindeki yöntemleri komut deseni sınıf (lar) / cephe'den çağırırsınız. UOW, veritabanı IO'sunu daha sonraya kadar basitçe savunduğundan (uzun süreli işlemlerin veya veritabanına gereksiz olabilecek birden çok çağrının olmasını önlemek için), UOW ile çalışmak normalde veritabanınızla çalışacağınız düzeyde olmalıdır.

Microsoft, UOW deseninde çok kapsamlı bir gönderiye sahiptir:

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx