Prism 3 - Unity Container 설명 - 디펜던시 인젝션 이라는걸 듣도 보도 못한 분들을 위해......

정말 어려운 주제 입니다.. 디펜던시 인젝션이라는 주제는... 이걸 어떻게 설명 해야 할지 참 난감 합니다.

저의 블로그에도 이전에 이 주제를 가지고 한번 포스팅을 한적이 있습니다. 

http://iopeni.tistory.com/entry/Dependency-Injection-Container

Dependency Injection in Action 이라는 책을 보면 DI를 가정집에 전기 콘센트로 비유 하고 있습니다. 뻔한 내용 이겠죠? 헤어드라이든 냉장고든 TV든 콘센트에 꽂혀야 동작을 하니 콘센트는 하나의 가전 제품에 생명력을 불어넣어 주는 ~~ 신비한 곳입니다. 만약 집에 있는 가전 제품들이 모두 특수한 가전제품이라 각기 다른 전기 어댑터를 지니게 된다면, 아마 콘센트의 양은 정말 어마 무시하게 많아 지겠지만, 다행 스럽게 대한민국의 콘센트는 같은 모양을 지니고 있습니다.

이런 일을 컴퓨터 언어적인 측면에서 설명을 하자면, 추상 클래스와 인터페이스 같은 것들로 설명을 할 수 있습니다. 

즉 다형성이라는 주제 인걸로 보입니다. 추상이나 인터페이스의 목적이 좀 모호합니다만, 알고보면 별거 아닙니다.

 

사실 정확하게 이야기 하자면 추상은 인터페이스와 비교하면 목적 자체가 틀립니다. 추상은 콘센트 라기 보다 가전 제품의 종류 입니다. 세상에 에어컨이 있는데 이 에어컨의 종류가 벽면 에어컨도 있고 스탠드 에어컨도 있고 지붕에 달려 있는 에어컨도 있고... 많은 형태의 에어컨이 존재 하지만 모든 에어컨은 공통인 것들 즉 에어컨은 바람이 나오고, 실외기가 있어야 하고, 프레온 가스로 찬 바람을 만들고, 등등 기본적인 성격을 모든 에어컨이 지니게 되는데 이것이 바로 추상 클래스 입니다. 프레온 가스가 있는 이 프레온 가스는 A 회사 제품도 있고, B회사 제품도 있고 다 틀리니 말이죠.

인터페이스는 다릅니다. 

인터페이스는 항구, 공항, 콘센트, 주유소, 세차장, 책장 등과 같습니다. 항구에는 수많은 종류의 배들이 정박 할 수 있는 곳이며, 공항은 수많은 종류의 비행기가 뜨고 내리는 곳입니다. 하나의 객체와 또 다른 객체를 이어주는 연결 고리 라고 생각 하면 됩니다.

물론 이런걸 관점주의적 프로그래밍 이라는 주제로 바라 보면 또 약간의 차이점이 발생 하기도 합니다.

각설하고 말이죠 더 깊에 설명 하려고 하면 골 때리고, 닭이 먼저 인지 달걀이 먼저인지.... 니가 나 인지.. 내가 너 인지 모르는 사태가 발생 할 수 있으므로 우리는 여기서 딱 한가지만 정하고 가야 할 듯 합니다.

오늘은 인터페이스 입니다. 인터페이스 하나만 알면 됩니다.

이걸로 디펜던시 인젝션 이라는 주제를 설명 하고자 합니다. OOP적 관점에서의 인터페이스 라고 하면 이 아무것도 아닌 개념이 정말 난해하게 느껴져 절망을 부르짓고 있는 분이 계실지도 모르겠습니다.

사실 디펜던시 인젝션의 모든 테크닉은 이 인터페이스 에서 비롯 됩니다.

하나의 클래스에서 맴버가 등록 되는데 이 멤버의 타입이 인터페이스 인겁니다. 즉 맴버는 인터페이스를 상속 받은 다양한 클래스들이 이 멤버에 대입 될 수 있으며, 정보를 취득 가공함에 있어 형 변환 연산이 필요하지 않은 것입니다.

마이크로 소프트는 유니티를 다음과 같이 설명 하고 있습니다. https://msdn.microsoft.com/library/ff647202.aspx

오늘 우리는 이 유니티 컨트롤을 사용하는 기초적 용법을 습득하고 다음 포스트에서 다시 프리즘으로 넘어가서 또 다른 주제를 풀어 볼까 합니다.

콘솔로 또 헬로우 월드를 표시 하는 걸로 이 샘플을 예시 합니다. 일단 콘솔 어플리케이션 프로젝트를 하나 생성 합니다.

그리고 NuGet 패키지 관리자를 실행 시키고 Unity를 찾습니다.

화면으로 보여 드리죵~

요걸 설치 하시면 됩니다. 

코드 봐야 겠죠?

재미있는건 우리가 알고 있는 간단한 IoC 컨테이너는 타입을 넣어 주고 new로 생성된 인스턴스를 넣어서 사용 하고자 할때 타입으로 찾아 꺼내 쓰는 모습 이었는데 이건 좀 다르게 보입니다.

이녀석은 우리가 new를 사용하지 않아도 자신이 new를 해서 반환해 줍니다. 이렇게 생각 하면 좀 이상하게 보이는게 있는데 new를 하는게 언제하냐는 겁니다. 

그래서 아주 간단한 방법으로 테스트 해 보았습니다.

Container.ResisterType 항목을 주석 처리 하고 Resolve에 직접 클래스를 적어주니 객체를 생성해서 반환 합니다.

다음과 같이요..

var test = container.Resolve<Hello>();

와 같이요... 

혹시 기억 하실지 모르겠습니다. Prism 1 에서 MainWindow 를 Resolve 하던 코드를... 거기에선 ResisterType을 하지 않았습니다.

그럼 ResisterType은 무엇일까요? 이건 Dictionary<T, T> 를 사용해 보신 분이라면 아실껍니다. 키를 가지고 실 데이터를 찾게 되는데 그 실 데이터의 타입을 정해 주는 겁니다. Dictionary와 같습니다. 단~ 틀린게 있다면 딕셔너리는 Object 를 등록하게 되지만 여기서는 Type을 등록 하네요~ 즉 정확한 의미는 이겁니다. 만약 인터페이스 타입으로 누군가 Resolve를 요청 하면 이 클래스를 생성해서 반환 하도록 한다.. 라는 사전 지정 입니다.

한번 생각해 보도록 하죠. 만약 유니티 컨테이너를 특정 유틸리티 클래스의 static member로 놓고 거기에 오만 가지 사용하고 있는 클래스를 등록 합니다. 예를 들어 이런 것들이요.. Logger나 File처리 클래스, 통신 클래스 같은 것들이요. 필요할 때 마다 불러서 쓸 수 있겠네요. 프로젝트 전역에서. 참 유용 하겠죠? 

한가지 더 주의 사항이 있습니다. container.RegisterType<IISayHelloWold, Hello2>(); 여기서 interface가 Key 입니다. 

같은 Key를 두번 등록 하면 어떻게 될까요? 바꿔 치기 됩니다. 주의 하시기 바랍니다.

오늘도 수고 하세요~