2 Results for 'Pattern&Practice'

  1. 2009.02.19 Prism 2.0 for WPF & Silverlight
  2. 2009.01.30 라이브러리 문서화의 중요성 (2)

[추가]
앗! 아니나 다를까 킹크랩에 잘 소개가 되어 있었군요. 필독!
http://kingcrap.com/entry/Composite-Application-Guidance-for-WPF-June-2008-Release
[수정]
앗! 이건 작년에 나왔던 WPF 전용 버전에 대한 내용이었네요;; 날짜를 잘 못봤습니...
그래도 기본 골격은 같으니 참고;;
--------------------------------------------------------------------------------------

Pattern & Practice 팀에서 다시 한번 유용한 라이브러리를 공개했네요. Prism이란 이름으로 개발되던 라이브러리인데 버전 2.0이 되면서 'Composite Application Guidance for WPF & Silverlight'라는 무시무시한 이름으로 공개를 했네요. 걍 프리즘이라고 계속  부르면 안되나 –_-;

Composite Application Guidance(이하 프리즘 2–_-)는 WPF와 실버라이트 애플리케이션을 보다 모듈화 된 형태로 쉽게 만들기 위해 디자인되었다고 해요. Guidance라는 거창한 이름이 붙은건 이 배포 패키지가 단순히 라이브러리 뿐만 아니라 즉시 실행해 볼 수 있는 핸즈온랩과 XAML 및 디자인 패턴 가이드를 포함하고 있기 때문이에요.

프리즘 2는 사실 엔터프라이즈 비즈니스 영역에 포커스를 주고 있는데요, 많은 패턴이나 라이브러리/프레임워크가 그렇듯이 애플리케이션에 따라 이 라이브러리를 도입했을 때 장점이 클 수도 그렇지 않을 수도 있겠죠. 그러나 만약 비슷한 패턴이 필요로 할 때 이렇게 검증된 라이브러리를 쓰는 것이 직접 개발하는 것에 비해 훨씬 큰 이득을 얻을 수 있을 거에요.

요즘은 너무 바빠서 자세히는 못봤고, 링크 모음:

http://blogs.msdn.com/blaine/archive/2009/02/18/prism-2-0-is-live.aspx

http://msdn.microsoft.com/en-us/library/dd458809.aspx

저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo

요즘 실버라이트용 DI(Dependency Injection) 프레임워크로 Pattern&Practice 팀에서 제공하는 Unity Application Block과 독특한 특징을 가진 Ninject, 이 둘을 보고 있죠. 사실 DI의 원리나 구성은 대략 파악했다고 생각하는데 실제 구현은 참 난감한 부분이 많은 것 같아요. 그래서 우리는 이런 공개된 프레임워크의 덕분에 좀 더 쉬운 삶-바로 제가 추구하는 그것!-을 살 수 있어요.

여튼 이 둘은 서로 스타일이 꽤 달라요. 우선 네이밍 부터가 꽤 달라서 이게 과연 같은 패턴을 사용하는 그것이 맞나 싶을 정도. 아주 조금씩만 써보고 있어서 아직 확실하게 감은 못잡았지만 공부하면서 느끼는 차이는 바로 문서화의 차이에요.

Unity는 마이크로소프트의 P&P에서 나온 만큼 철저하게 MSDN 스타일로 구성되어 있죠. MSDN의 장점은 어떤 라이브러리를 매우 광범위하고 자세하게 기술하고 있다는 점인데요 반면 단점은 Getting started를 봐도 딱 그 정도까지만 쓸 수 있을 뿐 그 이상의 기능을 구현하려면 어떤 클래스를 어떻게 사용할지 찾기가 꽤 어렵다는 점이죠. 그래도 최근엔 HOWTO 토픽도 많이 생기고 해서 이런 점은 많이 해소 되었지만, 그래도 여전히 문서가 너무 딱딱해서 어느정도 기합을 넣고 보지 않으면 잘 읽히지가 않아요.

Ninject는 일단 메인 사이트 부터가 굉장히 팬시해서 둘러보는데 부담이 없어요. 그리고 Ninject는 MSDN처럼 완전히 정리된 문서따위는 없지만 Wiki를 통해 아주 깔끔하게 스텝별로 익힐 수 있도록 되어 있어요. 이게 중요한데요, Ninject는 Ninject를 설명할 때 기능 하나하나에 대한 사용법이나 설명을 독립적으로 하는게 아니라 단계별로 기본적인 사용법과 함께 Ninject가 어떤 부분에 주안점을 가지고 있는지 이해할 수 있도록 구성되어 있죠.

베스트 케이스라면 Getting started를 Ninject스타일로 친절하게 구성하고 세부적인 레퍼런스를 MSDN 스타일로 구성하는 거지만 둘 중 하나를 선택하라면 Ninject 스타일의 손을 들어주고 싶네요. 왜냐면 프레임워크나 라이브러리라는 건 일단 처음 사용하기가 굉장히 괴롭거든요. 일종의 진입 장벽이랄까요? 그런 걸 쉽게 덜어주고 그 라이브러리의 설계 철학이나 흐름을 잡는게 중요하다고 봐요.

왜 이런 소릴 하고 있냐면…

Ninject에서는 모듈(Unity의 컨테이너 개념)에 인터페이스와 클래스의 바인딩을 등록할 때 아주 간단하면서도 유용한 조건을 붙여서 하나의 인터페이스에 여러개의 클래스를 조건에 따라 자동으로 인젝션 되도록 되어 있어요. 예를 들면,

public class Swordsman { 
  [Inject] public IWeapon Weapon { get; set; } 
}

public class Ninja { 
  [Inject] public IWeapon MeleeWeapon { get; set; } 
  [Inject, Range] public IWeapon RangeWeapon { get; set; } 
}

Bind().To(); 
Bind().To().Only(When.Context.Target.HasAttribute());

이건 “IWeapon이라는 인터페이스를 Sword클래스와 Shuriken(수리검^^) 클래스에 바인딩을 하되 Context.Target(인젝션 대상, 여기에서는 Weapon, MeleeWeapon, RangeWeapon과 같은 프로퍼티)이 RangeAttribute라는 어트리뷰트를 가지고 있을 때만 Shuriken을 바인딩 해라”를 의미해요. 정말 기가 막히게 팬시하면서 읽기 쉬운 코드 아닌가요? 거의 영어 문장을 읽는 것과 비슷하게 느껴질 정도로요.

또한 예제 코드 역시 Foo나 Bar 따위가 아니라 검사(Swordman)과 닌자(Ninject를 떠올리는!)가 각각 자신의 역할에 맞게 사용할 무기들을 선택하는 과정이 머리속에 그려지도록 잘 선택되었고요.

다른 방법의 예제를 보면

public class Ninja { 
  [Inject] public IWeapon MeleeWeapon { get; set; } 
  [Inject, Tag("range")] public IWeapon RangeWeapon { get; set; } 
}

Bind().To(); 
Bind().To().Only(When.Context.Tag == "range");

비슷한데 Tag라는 미리 지원되는 어트리뷰트를 가지고 문자열 비교를 할 수 있게 한거에요. 이러면 매번 어트리뷰트를 새로 만들지 않아도 되니 편리하겠죠. 마찬가지로 문장은 정말 쉽게 읽히고요.

거기에 한 단계 더 생각해서, 단지 인젝션 대상의 이름 규칙(convention)만으로도 바인딩 할 수 있게 지원하죠.

public class Service { 
  public Service(ISource remoteSource, ISource localSource) { 
    //... 
  } 
}

Bind().To().Only(When.Context.Target.Name.BeginsWith("remote")); 
Bind().To().Only(When.Context.Target.Name.BeginsWith("local"));

Service라는 클래스는 생성될 때 두 개의 ISource를 받죠. 아래의 바인딩 문은 이 클래스에 인젝션할 때 “타겟이 remote라는 이름으로 시작할 때”, “타겟이 local이라는 이름으로 시작할 때”라는 조건을 붙인 걸 읽을 수 있어요. (진짜 볼 수록 감탄…)

참 쉽죠? (ㅋㅋ)

반면 Unity에서 비슷하게 하나의 컨테이너에 하나의 인터페이스를 여러 개의 클래스와 바인딩하고 싶은데 도무지 어디에서 그런 설정을 해야할지 난감하네요. 아마도 Configuration이라는 클래스를 상속받아 구현하는 것 같은데 실버라이트용에서는 그 Configuration이 빠졌다고 하는군요. 여튼 “동적인 조건부 인젝션”을 어떻게 할지 난감해요.

네, 솔직히 저는 Ninject의 손을 들어주고 있는데요, 다만 Unity for Silverlight는 단일 어셈블리에 용량도 조금이나마 작아서 딱 DI만 쓴다고 봤을 때 좀 더 가벼운데 Ninject는 3개의 어셈블리에 용량도 약간 더 커요. 그래서 Unity쪽도 해보고 둘 중에 하나를 선택하자..는 기분으로 써보고 있는데 이놈의 Unity 문서는 읽다보면 스르르 잠에 빠져서 진도가 안나가네요 ㅠ.ㅜ

그래서 오늘의 결론.

라이브러리 문서화를 잘 합시다. 이왕이면 단계별로 가장 핵심적인 내용을 익힐 수 있도록!
AND
Unity 써보신 분 조건적 인젝션 바인딩을 컨테이너에 어떻게 넣는지 좀 알려줍쇼 ㅠ.ㅜ 굽신굽신 oTL oTL

저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo


티스토리 툴바