필자는 Active Directory와 SQL 데이터베이스에 지속성으로 액세스해야하는 DDD 기반 시스템을 구축하는 고유 한 상황이 있습니다.여러 데이터 저장소를 처리 할 때 저장소 패턴과 작업 단위를 어떻게 구현합니까?
public interface IUnitOfWork
{
void BeginTransaction()
void Commit()
}
우리의 저장소는 다음과 같이 보았다 : 처음에이 우리의 디자인은 우리가이처럼 보였다 작업 단위 있었다 설정했기 때문에 문제가 않네이 설정에서
public interface IRepository<T>
{
T GetByID()
void Save(T entity)
void Delete(T entity)
}
을 우리의 부하 및 저장 우리가 직접 작성했기 때문에 두 데이터 저장소 간의 매핑을 처리합니다. 작업 단위 (UOW)는 트랜잭션을 처리하고 리파지토리가 지속성을 위해 사용할 Linq To SQL 데이터 컨텍스트를 포함합니다. 활성 디렉터리 부분은 인프라에서 구현되고 각 Save() 메서드의 저장소에서 사용되는 도메인 서비스에 의해 처리되었습니다. Save()는 데이터 컨텍스트와 상호 작용하여 모든 데이터베이스 작업을 담당했습니다.
이제 엔티티 프레임 워크에 적용하여 POCO를 활용하려고합니다. 이상적으로는 도메인 객체가 객체 컨텍스트에 의해 추적되기 때문에 Save() 메서드가 필요하지 않으며 객체 컨텍스트에서 변경 사항을 저장하도록 작업 단위에 Save() 메서드를 추가하면됩니다. 새 객체를 컨텍스트에 등록합니다.
public interface IUnitOfWork
{
void BeginTransaction()
void Save()
void Commit()
}
public interface IRepository<T>
{
T GetByID()
void Add(T entity)
void Delete(T entity)
}
이 엔티티 프레임 워크 데이터 액세스 문제를 해결하지만, 우리의 Active Directory 통합 문제가 해결되지 않습니다 : 새로운 제안 된 디자인은 더 다음과 같습니다. 전에는 저장소의 Save() 메소드에 있었지만 이제는 집이 없습니다. 작업 단위 (UOW)는 엔티티 프레임 워크 데이터 컨텍스트 이외의 것을 아는 것이 아닙니다. 이 논리는 어디에서 가야합니까? 필자는 엔티티 프레임 워크를 사용하는 데이터 저장소가 하나 뿐인 경우에만이 디자인이 작동한다고 주장합니다. 이 아이디어에 가장 잘 접근하는 방법은 무엇입니까? 이 논리는 어디에 두어야합니까?