Castle.Windsor 3.0 이 Release 되었습니다.

RC1 이 나온지 얼마 되지 않아, 정식버전이 출시되었네요.
http://docs.castleproject.org/Windsor.Whats-New-In-Windsor-3.ashx 를 참고하시면 도움이 됩니다.

다만, FluentRegistration API 에서 몇 가지 제거된 API 가 있어, Upgrade 하는데, 좀 헷갈렸습니다. 그래도 Resharper 의 도움으로 유사한 메소드를 찾는데, 상당한 도움을 받아, 반나절만에 Upgrade를 마쳤습니다.

언젠가 Castle.Windsor 3.0 Fluent Registration API 에 대해 정리해서 올리도록 하겠습니다.

Castle.Windsor 3 에서 Fluent Registration API 추가 기능

이제 얼마 안 있으면 Castle.Windsor 3 가 정식으로 Release 됩니다. 아직까지는 2.5.4 버전을 쓰고 있습니다만, 제가 뭐 엄청 잘 쓰는 게 아니므로, 크게 불만은 없습니다.

원문 : What's new in Windsor 3

요번에 Fluent Registration API 를 공부하면서, 좀 아쉬웠던게, 코드상으로 작업하면서, 환경설정 정보와 연동될 수 있다면, 웹 Application 에서는 아주 유용하겠다 생각을 했는데, 우연히 Castle.Windsor 3 의 새로운 기능으로 추가가 되는 군요.

Dependency class 라고

Container.Register(
   Component.For<ClassWithArguments>()
      .DependsOn(
         Dependency.OnAppSettingsValue("arg1"),
         Dependency.OnAppSettingsValue("arg2", "number"))
);
 
var instance = Container.Resolve<ClassWithArguments>();

라고, AppSettings 에 있는 정보를 Component의 속성 값으로 설정할 수 있는 기능이죠. 물론, 지금도 수동으로 만들 수 있지만, 기본으로 제공되면 더욱 좋다는 얘기입니다.

또 한가지가 모든 IWindsorInstaller 를 모든 Assembly에서 찾아서 인스톨하는 기능입니다.

container.Install(FromAssembly.InThisApplication())

보시다시피, 이 응용 프로그램과 참조하는 모든 어셈블리에 있는 모든 IWindsorInstaller 를 구현한 Installer 로부터 Install 을 수행하는 것입니다. 중복되는 것을 방지해주는 기능이 있으면 참 좋겠지만, 그건 Component 등록 시에 Unless 나 If 등 조건 등록을 사용하면 될 듯 하고, 관련된 Installer 찾아서 등록해주는 것도 일인데, 참 편리하죠.

마지막으로 OnCreate는 있는데, 정리하는 OnDestroy가 없었는데, 이번에 지원되는 군요.

container.Register(Component.For<MyClass>()
   .LifestyleTransient()
   .OnDestroy(myInstance => myInstance.ByeBye())
);

컴포넌트가 컨테이너로부터 해제될 때 발생합니다… 컴포넌트 자체에서 뭔가 할 일도 있을테고, Container 도 컴포넌트의 Lifecycle에 대한 이벤트를 제공하지만, 특정 컴포넌트에 대해, 외부에서 뭔가 지정할 수 있다는 점은 큰 장점이지요.

다른 다양한 기능들이 추가되었지만, 위의 3가지 기능이 참 쓸만 한 것 같습니다.

Castle.Windsor Fluent Registration API 소감

제목에 있듯이, 오늘 Castle.Windsor의 Fluent 방식의 Component 등록과 관련된 내용을 읽어보고, .NET 과 Silverlight 에 적용해 봤습니다.

물론 잘 됩니다.^^

그리고 제가 그 동안 사용하던 API 보다 훨씬 편한 방법도 많이 나왔고, Intercepter 등록한다던지, IWindsorInstaller를 이용하여 한방에 등록이 가능하다는 게 상당한 장점이 될 것 같습니다.

문제는 이러한 방식이 Silverlight에서는 선택의 여지가 없지만, .NET 기반에서는 아직도 xml 기반 설정파일이 대세라는 점이고, 이 부분은 컴파일 없이도, 환경을 변경시켜, 컴포넌트의 구조를 변경시킬 수 있는 장점이 있습니다.

기존 Xml  방식과 Fluent 방식에 대해 비교해 보면…

기존 Xml 파일 방식

• 환경설정 파일의 일부분으로 text 파일로 표현하여, 수정 시 컴파일이 필요 없습니다.
• 다른 IoC 라이브러리들도 비슷한 환경설정 파일을 제공합니다.
• 새로운 API 를 배울 필요가 없습니다.^^

Fluent API 방식

• API 방식이므로, 컴파일 시에 설정 중의 수형에 대한 부분의 검증은 이루어집니다. (xml 에서는 돌려봐야 알죠)
• 한번에 많은 컴포넌트를 등록할 수 있습니다. (또한 Filterling 을 통해 선택적으로 등록할 수도 있습니다)
• Conditional Compile 을 통해 선택적으로 등록 코드를 실행할 수 있습니다. (.NET, Silverlight 별로 각각 다른 것을 등록)
• 동적 등록이 가능

자, 이 글을 보시고, 각자 판단할 것이지만, NHibernate 의 Hbm 과 FluentNHibernate 의 Mapping API  의 비교와 유사하다고 볼 수 있습니다. 그런 면에서 Fluent API 방식에 손을 들어주고 싶습니다.

단 하나 마음에 걸리는 것이 컴파일을 다시 해야 한다는 점입니다.
뭐 이 부분은 Option 으로 처리할 수 있지 않을까 생각해봅니다.

또 한가지 방식은 IWindsorInstaller 로 묶음으로 등록기를 만들고,  XML 환경설정 파일에서 <installer /> 를 이용하여, 등록하고, 변경하는 것입니다. 물론 이 방법도 Installer 를 어떻게 나누냐에 따라 말이 많아지겠죠.