DDD를 완전히 수행하지는 않지만 리포지토리 패턴이 매력적이며 집계 루트 경계를 따라 저장소를 분할하려고합니다. 엔티티 프레임 워크 위에 리포지토리를 구현하고 있습니다. 여기에서 ObjectContext는 엔터티에 대한 변경 내용을 추적하고 SaveChanges가 호출 될 때 적절한 SQL을 생성 할 때 작업 단위 스타일을 허용합니다.작업 단위 또는 ActiveRecord가있는 저장소 patten의 위치가 어느 정도 일치합니까?
저장소 내에서 SaveChanges를 호출 할 때 서로 다른 두 가지 접근 방식으로 어려움을 겪고 있습니다. 단점은 내가 단위 작업 (unit-of-work) 또는 활성 레코드 의미론을 채택하고있는 것처럼 보입니다. 내가 저장소 인터페이스를 정의하면 다음과 같이보고 :
public void Add(Document entity)
{
DB.AddToDocumentSet(entity);
GetUnitOfWork().SaveChanges(); //delegates to the ObjectContext's SaveChanges
}
public interface IRepository<T>
{
T Get(int id);
IList<T> GetAll();
IQueryable<T> Query();
void Delete(T entity);
void Add(T entity);
IUnitOfWork GetUnitOfWork();
}
및 IUnitOfWork을
public interface IUnitOfWork
{
void SaveChanges();
}
구현으로, 나는 두 가지 선택을 갖고있는 것 같다
또는
public void Add(Document entity)
{
DB.AddToDocumentSet(entity);
}
전자의 경우 저장소의 Add 메서드가 각 작업에서 SQL을 보냅니다. 후자의 경우 호출 코드는 저장소에서 작업 단위 (UOW)를 확보하고 적절한 것으로 판단되면 SaveChanges를 호출합니다. 이렇게하면 작업 단위가 다른 저장소로 확장 될 수 있습니다 (각 저장소가 해당 구조에서 동일한 작업 단위를 확보하도록 보장합니다).
나의 두 번째 접근 방식은 더 유연하다는 느낌입니다. 작업 단위 패턴을 채택한다는 것은 호출 코드가 리포지토리에서 반환 한 엔터티의 속성을 간단히 업데이트 한 다음 UnitOfWork.SaveChanges를 호출한다는 점에서 엔티티에 대한 업데이트가 조금 더 멋지다는 것을 의미합니다.
저장소 패턴을 사용할 때 일반적으로 다른 방법보다 선호되는 방법이 있습니까?