참고 :이 답변은 Entity Framework에 대해 이야기 DbContext하지만 LINQ to SQL DataContext및 NHibernate 와 같은 모든 종류의 작업 단위 구현에 적용됩니다 ISession.

Ian을 반향하여 시작하겠습니다 DbContext. 전체 응용 프로그램에 대해 하나 를 갖는 것은 나쁜 생각입니다. 이것이 적합한 유일한 상황은 단일 스레드 응용 프로그램과 해당 단일 응용 프로그램 인스턴스에서만 사용되는 데이터베이스가있는 경우입니다. 는 DbContext스레드 안전하지하고 있기 때문에 DbContext데이터를 캐시, 그것은 오래된 곧 가져옵니다. 이렇게하면 여러 사용자 / 응용 프로그램이 해당 데이터베이스에서 동시에 작업 할 때 모든 종류의 문제가 발생합니다 (물론 매우 일반적입니다). 그러나 나는 당신이 이미 그것을 알고 있고 그것을 필요로하는 사람에게 새로운 인스턴스 (즉, 일시적인 생활 방식)를 주입하지 않는 이유를 알고 싶어 DbContext합니다. (단일 DbContext스레드 당 또는 컨텍스트 당 컨텍스트가 나쁜 이유에 대한 자세한 내용은 이 답변을 읽으십시오 ).

DbContext일시적 으로 as 를 등록하면 효과가 있지만 일반적으로 특정 범위 내에서 이러한 작업 단위의 단일 인스턴스를 가지기를 원합니다. 웹 응용 프로그램에서는 웹 요청의 경계에 이러한 범위를 정의하는 것이 실용적입니다. 따라서 웹당 요청 라이프 스타일입니다. 이를 통해 전체 개체 집합이 동일한 컨텍스트 내에서 작동 할 수 있습니다. 즉, 동일한 비즈니스 트랜잭션 내에서 작동합니다.

동일한 컨텍스트 내에서 일련의 작업을 수행하려는 목표가 없으면 일시적인 라이프 스타일은 좋지만 몇 가지주의해야 할 사항이 있습니다.

• 모든 객체는 자체 인스턴스를 가져 오므로 시스템 상태를 변경하는 모든 클래스는 호출해야합니다 _context.SaveChanges()(그렇지 않으면 변경 사항이 손실 됨). 이는 코드를 복잡하게 만들고 코드에 두 번째 책임 (컨텍스트 제어 책임)을 추가하며 단일 책임 원칙을 위반하는 것입니다 .
• DbContext다른 클래스의 컨텍스트 인스턴스에서 사용할 수 없으므로 [로드하여 저장 한 ] 엔터티가 해당 클래스의 범위를 벗어나지 않도록해야합니다. 엔티티가 필요할 때 ID로 다시로드해야하므로 성능 문제가 발생할 수 있기 때문에 코드가 엄청나게 복잡해질 수 있습니다.
• DbContext구현 하기 때문에 IDisposable여전히 생성 된 모든 인스턴스를 삭제하려고합니다. 이렇게하려면 기본적으로 두 가지 옵션이 있습니다. 을 호출 한 직후에 동일한 방법으로 처리해야 context.SaveChanges()하지만,이 경우 비즈니스 로직은 외부에서 전달 된 객체의 소유권을 가져옵니다. 두 번째 옵션은 생성 된 모든 인스턴스를 Http 요청의 경계에 배치하는 것입니다. 그러나이 경우 해당 인스턴스를 폐기해야 할시기를 컨테이너에 알리려면 범위를 지정해야합니다.

다른 옵션은 전혀 주입 하지 않는DbContext 것입니다. 대신 DbContextFactory새 인스턴스를 만들 수 있는 a를 삽입 합니다 (이전에이 방법을 사용 했었습니다). 이렇게하면 비즈니스 로직이 컨텍스트를 명시 적으로 제어합니다. 다음과 같이 보일 수 있습니다 :

public void SomeOperation()
{
    using (var context = this.contextFactory.CreateNew())
    {
        var entities = this.otherDependency.Operate(
            context, "some value");

        context.Entities.InsertOnSubmit(entities);

        context.SaveChanges();
    }
}

이것의 장점은 DbContext명시 적으로 수명을 관리하고 쉽게 설정할 수 있다는 것입니다. 또한 특정 범위에서 단일 컨텍스트를 사용할 수 있으므로 단일 비즈니스 트랜잭션에서 코드를 실행하고 엔티티가 동일한 위치에서 시작하므로 엔티티를 전달할 수있는 것과 같은 분명한 이점이 DbContext있습니다.

단점은 DbContext메쏘드에서 메쏘드 (메서드 인젝션이라고 함) 를 전달해야한다는 것입니다 . 어떤 의미에서이 솔루션은 ‘범위’접근 방식과 동일하지만 이제 범위는 응용 프로그램 코드 자체에서 제어되며 여러 번 반복 될 수 있습니다. 작업 단위 작성 및 처리를 담당하는 응용 프로그램입니다. DbContext의존성 그래프가 생성 된 후에 생성 되기 때문에 생성자 주입은 그림에서 벗어나므로 한 클래스에서 다른 클래스로 컨텍스트를 전달해야하는 경우 메소드 삽입을 연기해야합니다.

Method Injection은 그렇게 나쁘지는 않지만 비즈니스 로직이 더 복잡해지고 더 많은 클래스가 참여할 때 메소드에서 메소드로, 클래스로 클래스를 전달해야합니다. 이것은 과거에). 간단한 응용 프로그램의 경우이 접근법은 잘 작동합니다.

단점으로 인해이 팩토리 접근 방식은 더 큰 시스템에 적용되며 다른 접근 방식이 유용 할 수 있으며 이는 컨테이너 또는 인프라 코드 / 컴포지션 루트 가 작업 단위를 관리하게하는 접근 방식입니다. 이것이 당신의 질문에 관한 스타일입니다.

컨테이너 및 / 또는 인프라에서이를 처리 할 수있게함으로써 UoW 인스턴스를 생성 (선택 사항) 커밋 및 처리하여 비즈니스 로직을 단순하고 깨끗하게 유지함으로써 애플리케이션 코드가 오염되지 않습니다 (단일 책임). 이 방법에는 몇 가지 어려움이 있습니다. 예를 들어, 인스턴스를 커밋하고 처리 했습니까?

작업 단위 처리는 웹 요청이 끝날 때 수행 할 수 있습니다. 그러나 많은 사람들 이 이것이 작업 단위를 커밋하는 장소라고 잘못 생각합니다. 그러나 애플리케이션의 시점에서 작업 단위가 실제로 커밋되어야하는지 확인할 수 없습니다. 예를 들어 비즈니스 계층 코드가 콜 스택에서 더 높은 예외를 발생시킨 경우 커밋 하지 않을 것 입니다.

실제 솔루션은 다시 일종의 범위를 명시 적으로 관리하는 것이지만 이번에는 컴포지션 루트 내에서 수행합니다. 명령 / 핸들러 패턴 뒤에있는 모든 비즈니스 로직을 추상화 하면이를 수행 할 수있는 각 명령 핸들러를 감싸는 데코레이터를 작성할 수 있습니다. 예:

class TransactionalCommandHandlerDecorator<TCommand>
    : ICommandHandler<TCommand>
{
    readonly DbContext context;
    readonly ICommandHandler<TCommand> decorated;

    public TransactionCommandHandlerDecorator(
        DbContext context,
        ICommandHandler<TCommand> decorated)
    {
        this.context = context;
        this.decorated = decorated;
    }

    public void Handle(TCommand command)
    {
        this.decorated.Handle(command);

        context.SaveChanges();
    } 
}

따라서이 인프라 코드를 한 번만 작성하면됩니다. 모든 견고한 DI 컨테이너를 사용하면 그러한 데코레이터가 모든 ICommandHandler<T>구현을 일관된 방식으로 감싸도록 구성 할 수 있습니다 .

답변