3

중요한 아키텍처 문제가있는 대규모 C# 엔터프라이즈 프로젝트에서 작업하고 있습니다. 이러한 문제 중 하나는 모든 곳에서 StructureMap 컨테이너에 대한 정적 참조가 있다는 것입니다 (정적 서비스 로케이터). 물건을 고정하기위한 첫 번째 단계로서 우리는 컨테이너를 생성자에 전달하고 정적 컨테이너 참조를 제거합니다.엔티티 프레임 워크 : 다른 옵션에 문제가있을 때 엔티티에 종속성 주입

아쉽게도 Entity Framework에서 만든 엔터티의 정적 컨테이너에 대한 호출이 있습니다. 이러한 종속성을 해당 엔티티의 클라이언트까지 밀어 넣는 것은 이러한 빈도가 얼마나 자주 발생하는지와 변경 범위에 기인하여 지금 당장 실행할 수 없습니다. 우리의 목표는 정적 컨테이너를 제거하고이를 관리하기 위해 많은 변경을 가하는 것입니다.

엔티티 프레임 워크로 엔티티에 컨테이너를 삽입하고 싶습니다. 대신 엔티티 프레임 워크에서 엔티티를 만들 때 컨테이너를 삽입하고 싶습니다. 사전 :

+0

엔티티에서 종속성을 이동 및 서비스 로케이터로부터 주입 의존성 전환이 계획의 일부이지만 한 번에 한 단계 ... – nash

답변

3

을 나는 서비스가 생성자를 통해 엔티티로 주입 될 수 어딘가에 몇 년 전에 읽은 기억,하지만 어쩌면 내가 약 IDbDependencyResolver 다른 서비스를 제공하는 읽었는데, 지금은 그것을 찾을 수 없습니다에

감사합니다 목적.

일시적인 해결책으로 나는 IHaveServiceLocator 같은 인터페이스로 엔티티를 표시하고 ObjectMaterialized 이벤트를 사용하는 것이 좋습니다.

public interface IHaveServiceLocator 
{ 
    IServiceLocator ServiceLocator { get; set; } 
} 

그리고 dbContext를 작성하는 장소는 서비스 위치 지정자에 액세스해야 생성 된 엔티티로 설정할 수 있습니다.

((IObjectContextAdapter)dbContext).ObjectContext.ObjectMaterialized += (s, e) => 
{ 
    var entity = e.Entity as IHaveServiceLocator; 

    if (entity != null) 
    { 
     entity.ServiceLocator = structureMapServiceLocator; 
    } 
} 
+0

덕분에, 매력처럼 작동한다. 인터페이스를 구현하고 컨테이너를 주입 할 수 있다는 것이 좋습니다. – nash

+0

이것은 매우 합리적입니다. 그러나 "servicelocator, 아! 반 패턴!"이라고 큰소리로 외치는 사람들이 있습니다. 네가 그들에게 뭐라고 말 하겠니? –

+0

@ jenson-button-event 서비스 검색기가 안티 패턴이며 개인적으로 거의 사용하지 않는다는 것에 확실히 동의합니다. 그러나 때로는 작업을 수행하고이 질문과 같이 전체 코드 기반을 다시 작성하지 않아도됩니다. –

관련 문제