리포지토리와 작업 단위 간의 관계

리포지토리를 구현하려고하며 리포지토리 소비자가 여러 작업을 수행 할 수 있기 때문에 UOW 패턴을 사용하고 싶습니다. 한 번에 커밋하고 싶습니다.

문제에 관한 몇 가지 기사를 읽은 후에도 다른 방법으로 수행되는 기사에 따라이 두 요소를 관련시키는 방법을 얻지 못합니다.

때때로 UOW는 저장소 내부에있는 것입니다.

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());
    }
}

때로는 외부 적입니다.

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

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

다른 경우에는 리포지토리를 참조하는 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());
    }
}

이 두 요소는 어떤 관련이 있습니까? UOW는 변경해야 할 요소를 추적하고 저장소에는 이러한 변경 사항을 유지하는 논리가 포함되어 있습니다. 마지막이 더 의미가 있습니까?

또한 누가 연결을 관리합니까? 저장소에서 여러 작업을 수행 해야하는 경우 동일한 연결을 사용하고 트랜잭션조차도 더 견실하다고 생각하므로 연결 개체를 UOW 내부에 넣고 저장소 내부의 개체도 의미가 있습니다.

건배

Re : "UOW는 변경해야 할 요소를 추적하고 저장소에는 이러한 변경 사항을 유지하는 논리가 포함되어 있습니다. 그러나 누가 누구를 호출합니까?"

이 수업의 기본 책임을 이해합니다. 읽은 각 기사는 서로 다른 방식으로 기사를 연결한다고 말합니다. 이는 "누가 누구에게 전화하는지"에 대한 결정이 귀하에게 달려 있음을 의미합니다.

Cohesion , Decoupling , Reusability , Unit-Testability 등과 같은 우수한 소프트웨어 디자인의 기본 원칙에 의해 안내되는 동안 '계층'측면에서 문제를 스케치하려고합니다 .

인용 에릭 에반스 도메인 기반 디자인, (2004) 애디슨 웨슬리, 69 페이지 :

[계층화 된 아키텍처]의 필수 원칙은 계층의 모든 요소가 동일한 계층의 다른 요소 또는 "아래"계층의 요소에만 의존한다는 것입니다.

제 생각에 UOW와 Repo는 명확하고 독립적 인 책임이있는 매우 다른 두 클래스입니다. 우선, 나는 다른 하나를 호출하지 않을 것입니다.

나는 repo에서 '언제 무엇을 얻을 수 있는지'와 거래를 저장하기 위해 '언제'를 실제로 알고 있는 제 3의 클라이언트 클래스 (즉, a controller또는 service class)가 필요하다고 생각합니다 . 이 클라이언트는 아키텍처가 상대적으로 높기 때문에 ( 더 많은 클래스에 대해 알 수 있음 ) 둘 사이에서 오케스트레이션을 수행 할 수 있습니다.

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

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


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

메소드는 UOW 인터페이스 (일반적으로 팩토리를 통해 구성됨)에 가장 일반적으로 제공됩니다.

일반적으로 명령 패턴 클래스 / 파사드에서 UOW 인터페이스의 메소드를 호출합니다. UOW는 나중에 데이터베이스 IO를 지연 시켜서 (오랫 동안 실행되는 트랜잭션이나 불필요 할 수있는 데이터베이스에 대한 다중 호출을 방지하기 위해) 지연시키기 때문에 UOW에 대한 작업은 일반적으로 데이터베이스에 대해 작업하는 레벨과 동일해야합니다.

Microsoft는 UOW 패턴에 대해 매우 철저한 게시물을 작성했습니다.

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