엔티티 프레임 워크/작업 단위 아키텍처 질문

Question

저는 UoW, 저장소 패턴 등에 매우 익숙하지만, Entity Framework 패턴의 다양한 구현을 보는 중에 왜 누군가가 Save 또는 Add 메서드를 사용하는지 궁금합니다. 그들의 저장소. 당신이 저장소를 사용하는 경우 당신에게 누군가가 이미

좀 디자인이 함께 알고있는

public Customer GetNewCustomer() 
{ 
    Customer customer = new Customer(); 
    ... any initialization code here ... 
    _context.Customers.AddObject(customer); 
    return customer; 
} 

, 당신은 단순히

 
Customer customer = new Customer(); 

를 사용하고 어디에서나 연결되지 않은 것입니다 상상 객체의 새로운 인스턴스를 얻을 수 있습니다 문맥에. 그러나 나는 개인 생성자의 팬이므로 Customer 객체에 대한 단일 인스턴스화 지점이 있습니다. 이를 염두에두고 UoW 패턴을 사용할 때 리포지토리에 추가/저장 메서드를 사용하지 않고 IUnitOfWork 인터페이스에서만이 기능을 사용하는 것이 바람직하지 않습니까?

Answer 1

Java에서 Spring 관용법을 따를 때, 작업 단위 (및 트랜잭션)는 서비스와 관련된다. 모델과 지속성 객체를 사용하여 요청을 수행합니다. 트랜잭션은 측면을 사용하여 시작됩니다.

.NET이 비슷한 아이디어를 가지고 있는지 여부는 알 수 없지만 탐색 해 볼 가치가 있습니다. 인터페이스 기반 POCO 서비스를 보유하고 트랜잭션을 소유하게하십시오.

Answer 2

귀하의 솔루션이 맞다고 생각하지 않습니다. 그러면 빈 고객이 현재 작업 단위에 추가됩니다. 즉, 현재 작업 단위로 고객을 저장하지 않기로 결정하면 나중에 코드를 작성하는 데 어려움이 있습니다.

저장소에는 엔티티를 저장하는 방법이있는 것이 일반적입니다. 당신은 도메인 기반 디자인

• 저장소

저장소의 책임을 검색하거나 저장하는 기관입니다

개체 공장에서 사용되는 두 개의 패턴을 결합하고 있습니다. 오브젝트 팩토리의 책임은 엔티티의 구축을 처리하는 것입니다.

btw. 저장소가 엔티티가 아닌 경우 엔티티의 개인 생성자가 저장소에서 액세스 할 수 없습니다 (이는 매우 나쁨).

Answer 3

...하고자하지가/추가 기능이없는 UOW 패턴을 사용할 때 저장소에 저장 방법 만 IUnitOfWork 인터페이스에이 기능 을 결코 의미가?

예 저는 IUnitOfWork 인터페이스에 Save 메서드 만있는 것이 합리적이라고 생각합니다. 그러나 EF와 함께 저장소 패턴을 더 이상 사용하지 않습니다. 대신 이제 & 쿼리 패턴의 thesevariations을 사용합니다.

EF DbContext는 실제로 엔티티 상태 읽기를위한 리포지토리, 2) 엔티티 상태 변경을위한 저장소, 3) UnitOfWork 여러 변경 사항을 추적하고이를 단일 트랜잭션으로 결합하여 상태 변이를 유지합니다.

그래서이 세 가지 책임을 3 개의 다른 인터페이스로 구분하지 않으시겠습니까?

public interface IUnitOfWork 
{ 
    int SaveChanges(); 
} 

public interface ICommandEntities : IQueryEntities 
{ 
    void Create(Entity entity); 
    void Update(Entity entity); 
    void Purge(Entity entity); 
} 

public interface IQueryEntities 
{ 
    IQueryable<AggregateRoot1> AggregateRoot1s { get; } 
    IQueryable<AggregateRoot2> AggregateRoot2s { get; } 
    IQUeryable<AggregateRootN> AggregateRootNs { get; } 

    IQueryable<TEntity> EagerLoad<TEntity>(IQueryable<TEntity> query, 
     Expression<Func<TEntity, object>> expression) 
     where TEntity : Entity; 
} 

그런 다음이 3 가지 인터페이스를 DbContext 클래스에 구현할 수 있습니다. 이것은 인터페이스를 훌륭하고 분리되게 유지하고 필요한 DbContext의 메서드 만 종속성에 삽입 할 수있게합니다.

예를 들어, 도메인은 지속성을 모르는 상태로 유지해야합니다. 이 경우 IUnitOfWork 인터페이스에 도메인 클래스 종속성을 부여하지 마십시오. 대신 IoC 작성 루트 (또는 MVC 작업 필터)에서 IUnitOfWork를 처리하십시오. 그런 다음 쿼리 및 명령 처리기는 ICommandEntities 및 IQueryEntities 인터페이스 만 처리합니다.