Unity Container 개체 풀이
회사에서 ^^ 재미있는 이야기가 오고 갔습니다. 먼저, 아래의 글은 이 이야기를 처음으로 꺼낸 ^^ resisa 님이 쓴 것입니다.
Spring VS Unity Container
; http://resisa.tistory.com/entry/Spring-VS-Unity-Container
저 같은 경우에도 처음에 그동안의 경험적인 생각을 바탕으로 Unity 역시 "등록" 과정을 거쳐야만 하는 것으로 여겼습니다. 더군다나 CAG(
Composite Application Guidance)를 하다보면 Module이란 개념이 나오는데 그를 다루는 ModuleCatalog에 등록된 어셈블리 내의 개체만이 Unity 컨테이너의 혜택을 본다고 생각했습니다.
실제로 ^^; 글을 그렇게 썼지요.
Unity 컨테이너 사용
; https://www.sysnet.pe.kr/2/0/697
위의 글에 보면, 타입을 등록하는 코드가 2군데 나오는데 IShell(Shell)과 DefaultStatusBar 개체입니다. 이를 "
Spring VS Unity Container" 글에 따라 다시 정리해 보면, Shell 개체를 IShell과 엮어서 등록하는 것은 필요하지만 DefaultStatusBar는 필요하지 않습니다.
요즘 진행하고 있는 CAG 응용 프로젝트에서도 초기에 이 사실을 몰라서 ^^; View와 ViewModel에 대해서 모두 등록하는 코드를 사용했었는데 나중에 알고 나서는 이런 코드를 싸악 정리해 버렸습니다.
Unity의 개체 풀이 과정은 사실 너무나 단순합니다. 예를 들어서, Unity를 다음과 같이 아주 간단하게 사용하는 프로젝트가 있다고 가정하면,
[그림 1: Unity 사용 예]
보는 것처럼 container.Resolve에 넘어가는 Class1 타입은 Unity에 전혀 등록된 적이 없습니다. 기본부터 생각해보면 이는 너무나 당연합니다. Type 자체가 구체적으로(Concrete) 명시되어 있기 때문에 Type.Ctor(생성자) 정보를 알아내서 호출해주면 그만이기 때문입니다. 물론, Ctor 안에 있는 인자 및 Type 내에 정의된 공용 Property 중에서 Dependency 특성을 가지고 있는 것들은 Reflection으로 검사해서 역시 해당 타입을 넘겨주면 되고!
이 때문에, Unity가 타입 풀이를 할 수 있는 범위는 현재 메모리에 올라와 있는 어셈블리 전체를 대상으로 합니다.
실제 코드를 보면, Resolve에 넘겨진 Type 정보로부터 생성자 정보를 가져오는 과정을 아래와 같이 거쳐서,
private ConstructorInfo FindInjectionConstructor(Type typeToConstruct)
{
ConstructorInfo[] injectionConstructors = Seq.Make(typeToConstruct.GetConstructors())
.Where(delegate(ConstructorInfo ctor)
{
return ctor.IsDefined(
typeof(TInjectionConstructorMarkerAttribute),
true);
})
.ToArray();
;
;
}
그 외 부가적인 Policy 등의 연동을 최종적으로 결정해서 다음과 같이 동적으로 코드를 생성하는 결과물을 해당 타입에 대해서 만들어두고 재사용을 하게 됩니다.
[SuppressMessage("Microsoft.Design", "CA1062:ValidateArgumentsOfPublicMethods")]
public override void PreBuildUp(IBuilderContext context)
{
Guard.ArgumentNotNull(context, "context");
DynamicBuildPlanGenerationContext buildContext =
(DynamicBuildPlanGenerationContext)context.Existing;
IConstructorSelectorPolicy selector =
context.Policies.Get<IConstructorSelectorPolicy>(context.BuildKey);
SelectedConstructor selectedCtor = selector.SelectConstructor(context);
// Method preamble - test if we have an existing object
// First off, set up jump - if there's an existing object, skip us entirely
Label existingObjectNotNull = buildContext.IL.DefineLabel();
buildContext.EmitLoadExisting();
;
;
}
이것을 기반으로 생각하면, "
Spring VS Unity Container" 글에서 설명한 몇몇 제약들이 이해가 갑니다.
- 객체를 Singleton으로 사용하고 싶을 경우
- IoC의 기능을 인터페이스를 통해서 받을 때
우선, 첫 번째 경우는 명시적으로 등록되지 않은 타입에 대해서는 TransientLifetimePolicy를 기본값으로 적용하기 때문에 Singleton 방식으로 사용하기 위해서는 설명된 데로 ContainerControlledLifetimeManager를 이용하여 등록해 주어야 합니다. (만약 반대로 기본값을 ContainerControlledLifetimeManager로 주었다면 현실적으로 사용할 때 더 불편했겠지요.)
두 번째 경우도 역시 명백해지죠. Type에는 Ctor 정보가 있지만 Interface에는 Ctor 정보가 없기 때문에 타입 풀이가 안됩니다. 따라서, Interface와 함께 Type이 연결되어서 등록되어야 하는 것입니다.
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]