2017-09-18 9 views
0

DI 용 Autofac을 사용하여 데스크탑 에디션 용으로 작성된 레거시 코어 라이브러리를 재사용하는 MVC UI 래퍼를 작성했습니다. 내가 직면하고있는 문제는, MVC가 InstancePerRequest를 필요로하는 동안 변경할 수없는 수명 라이브러리로 코어 라이브러리가 작동하고 있다는 것입니다.MVC 애플리케이션에서 Autofac LifetimeScope를 사용하는 단점

그래서 MVC에서 서비스를 InstancePerRequest 범위에 등록하면 요구가 완료되기 전에 코어 라이브러리에 의해 처리됩니다. MVC 응용 프로그램을 불행하게 만듭니다.
MVC 앱의 모든 서비스에도 LifeTimeScope를 사용해 보았습니다. 수명 범위는 요청 수명보다 짧기 때문에 MVC에서 작동하는 것으로 보입니다.

이 접근법에는 단점이 있습니까?

참고 : 레거시 코드에서는 항상 생성자를 통해 주입되는 대신 서비스가 수동으로 해결됩니다. 마찬가지로 :

using (var scope = IocContainer.BeginLifetimeScope()) 
{ 
    var service = scope.Resolve<IMyService>(); 
    return service.FindAll(); 
} 

답변

0

MVC 서비스 as noted in the documentation about sharing registrations across apps that have and apps that don't have request scopes에 대한 InstancePerLifetimeScope 작동합니다.

내 생각에는 잠재적으로 자신의 평생 범위를 만드는 데있어 두 가지 문제가 있다고 생각합니다. 당신이 그 (것)들과 살 수 있는지 당신이 너 자신을 위해 재판해야 할 것이다 그래서 다량 app 특정한이다.

문제 1 : 조기 폐기

당신의 예에서 당신은 어떤 일을하고 그 일을 반환, 공장 또는 서비스 IMyService가 해결되는 것을 보여줍니다. using 문 끝에 소유하고있는 수명 범위가 삭제됩니다. 즉, IMyService이 처리되고 (IDisposable 인 경우) IMyService에 필요한 종속성도 처리됩니다. 데이터베이스 컨텍스트 나 연결과 같은 경우에는 값을 업데이트하거나 삭제 된 연결에 대해 추가 데이터를 읽을 수 없기 때문에 반환 값이 유효하지 않게 될 수 있습니다.

문제 2 : 싱글/공유 문제

평생 범위는 때때로 작업 단위 또는 컨텍스트를 공유 할 필요 구성 요소 세트를 분리하는 데 사용됩니다. 예를 들어, MVC에서는 전체 요청에 대해 하나의 컨트롤러 인스턴스 만 가질 수 있습니다. 컨트롤러 개체를 몇 번이나 해결하더라도 요청은 동일한 인스턴스가됩니다. 전체 요청 수명 동안 할당 된 풀에서 하나의 연결까지 데이터베이스 연결과 비슷한 것을 볼 수 있습니다.

자신 만의 수명 범위를 작성하면 일종의 논리적 작업 단위도 생성됩니다. IMyService에 대한 종속성은 이 아니며이 나머지 MVC 요청과 공유됩니다. 사실 작은 수명 범위 인 은 자체 요청 인이거나 자체 작업 단위입니다. 중복 없음.

doc I linked to earlier에서 언급 한 바와 같이 그들은 모두 MVC 및 비 MVC 상황에서 사용되는 단지 MVC 요청의 의미가 회전 처리하자 및 범위 처분해야하는 경우 일반 해상도

, InstancePerLifetimeScope 사물을 등록 가능하다면.

문제가 해결되지 않으면 여기에서 문제를 해결할 수 있는지 또는 문제를 해결해야하는지 알아내는 것은 귀하와 앱 코드에 달려 있습니다. 당신이 그들을 다루어야 할 필요가 있다면, 그것도 특정 애플 리케이션이 될 것이므로 제공 할 "지도"가 없다 - 당신은 그것에 대해 스스로 생각하고있다.