많은 개발자들이 기다려온 Enterprise Library (EntLib) 5.0이 출시되었다. EntLib는 개발  과정에서 늘 고민하게 되는 공통적인 코드 블럭들을 마이크로소프트가 전세계 개발자들과 함께 고민하면서 발전시켜 나가고 있는 라이브러리성 프레임웍의 모음집이다. 시장에는 이미 많은 오픈 소스 기반의 라이브러리들이 있어 개발자의 노가다를 줄여주고, 시장에서 검증된 성능의 품질 좋은 코드셋을 앞다투어 쏟아내고 있다. 여기에 마이크로소프트도 거대 닷넷 생태계에 일원으로 참여하고 있는 것이다.

EntLib 5.0은 이전 4.1버전과 마찬가지로 아래와 같은 9개의 application block들로 구성되어 있다.

  • Caching Application Block. Developers can use this application block to incorporate a cache in their applications. Pluggable cache providers and persistent backing stores are supported.
  • Cryptography Application Block. Developers can use this application block to incorporate hashing and symmetric encryption in their applications.
  • Data Access Application Block. Developers can use this application block to incorporate standard database functionality in their applications, including both synchronous and asynchronous data access and returning data in a range of formats.
  • Exception Handling Application Block. Developers and policy makers can use this application block to create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications.
  • Logging Application Block. Developers can use this application block to include logging functionality for a wide range of logging targets in their applications. This release further improves logging performance.
  • Policy Injection Application Block. Powered by the Interception mechanism built in Unity, this application block can be used to implement interception policies to streamline the implementation of common features, such as logging, caching, exception handling, and validation, across a system.
  • Security Application Block. Developers can use this application block to incorporate authorization and security caching functionality in their applications.
  • Unity Application Block. Developers can use this application block as a lightweight and extensible dependency injection container with support for constructor, property, and method call injection, as well as instance and type interception.
  • Validation Application Block. Developers can use this application block to create validation rules for business objects that can be used across different layers of their applications.
  • 각 application block 사이의 dependency는 아래와 같다.

    image

    이전 버전에 비해 달라진 점 몇가지를 들면...
    * 아키텍처 리팩토링을 통해 DI 기능을 충실히 지원하여 테스트 및 유지보수성이 좋아짐
    * DI 컨테이너 비종속성. (기본은 Unity이며 Objectbuilder와 Unity가 하나로 합쳐져서 더이상 ObjectBuilder가 존재치 않음)
    * 비동기 데이타 접근 지원
    * 캐시 기능 향상
    * Unity 자체 성능 향상
    * 로깅 속도 향상
    * 어셈블리 숫자 감소
    * .NET Framework 4.0 지원, VS2010 통합  지원

    좀 더 상세한 정보를 볼 수 있는 싸이트로는 다음과 같은 곳이 있다.
    * MSDN
    * CodePlex
    * EntLib 5.0 개발 가이드
    * EntLib 5.0 문서

    Posted by 장현춘

    약간은 formal한 글을 포스팅하고 싶었지만, 차분히 앉아 이런 저런 형식을 갖춰가며 한편의 논문 쓰듯 글을 올린다는 것이 점점 불가능해짐을 느낀다. 블로그의 어원이 의미하듯 그냥 로그 남기듯 그때 그때 쓰고 싶을 글을 끄적임이 더 어울리는 것인지도 모른다.

    미팅을 준비하다가 지루하여 잠시 twitter에 올라온 글들을 보다 Channel9의 트윗 중 MEF에 관한 글을 보고나니, 한번쯤은 정리하고자 했지만 큰맘 먹고 다가서야할 것 같은 느낌에 미루던 것인지라 그냥 편한 마음으로 들어보았다.

    MEF가 무엇인지 알고 싶지만 많은 시간을 투자할 수 없는 분이라면 20여분 짜리 영문이지만, 아주 천천히 또박 또박 강의하는 아래 동영상을 추천한다.
    http://channel9.msdn.com/shows/10-4/10-4-Episode-26-Creating-Extensible-Applications-with-the-Managed-Extensibility-Framework/

    소개와 더불어 MEF를 통해 어떻게 코드가 만들어지는지를 보고싶은 분이라면 아래 Codeplex의 짤막한 글들을 참고하면 좋을 듯 하다.
    http://mef.codeplex.com/wikipage?title=Guide&referringTitle=Home

    영어라면 질색인 분이라면 Visual Studio 2010 공식 팀 블로그에 엄준일씨가 올린 글을 보면 좋을 듯 하다.
    http://vsts2010.net/category/.NET%20Framework%204.0/Managed%20Extensibility%20Framework 

    MEF가 처리하고 싶은 세상의 문제는 애플리케이션을 개발함에 있어서 수많은 모듈로 인한 복잡성을 관리하고, 개발에 필요한 모듈을 찾아 적절한 시점에 생성하는 수고를 개발자가 아닌 MEF가 처리할 수 있게 해주는 것이 아닐까한다.

    마이크로소프트가 Unity라는 DI 컨테이너를 내놓기 이전부터 닷넷 오픈 소스 개발자 생태계내에서는 이미 dependency를 줄여주어 유지보수를 용이하게 하는 많은 프레임웍이 생겨나 번성해왔다. 대표적인 것으로는 StructureMap, Windsor, Spring.net, NInject, Autofac 등.. 이런 즈음에 마이크로소프트가 닷넷 프레임웍 4.0에 기본으로 포함될 DI 컨테이러라고 할 수 있는 MEF 라이브러리를 내놓고 있는 것이다. 어찌 보면 개발자 입장에서 또 하나의 선택의 가짓수가 늘어났다고 할 수 있지만, 시장의 반응은 어떨지...

    1. 시장에서 오픈 소스 프레임웍인 NHibernate, iBatis.NET이 세를 불리고 있을 즈음 LINQ, Entity Framework 등을 마이크로소프트가 내놓았을 때, 그다지 인정을 받지 못하다가  조만간 정식 출시될 새 버전의 Entity Framework에 대해서는 개발자 사이에 기대가 점차 높아지는 것을 느낄 수가 있었는데...

    2. 아울러 시장에서 StructureMap, Windsor를 거쳐, Spring.net이 DI 컨테이너로 급부상하던 즈음에 마이크로소프트가 ObjectBuilder에 Wrapper 씌여 Unity를 내놓았다. 버전이 올라갈수록, Enterprise Library를 선호하는 사람일 수록 점차 Unity에 빠져드는데.... 한술 더떠 아예 닷넷 프레임웍에 기본 탑재되는 DI 기능의 라이브러리를 출시한다는데...

    얼마전 모회사의 아키텍트가 했던 섬뜩했던 말이 떠오른다.

    "마이크로소프트가 이것 저것 다 내놓는데, 굳이 시장에 있는 오픈 소스 프레임웍들이 필요할까요 ?"

    아직까지 공고하지 못해 개발자 생태계인지라 마이크로소프트라는 일개(?) 회사에 의해 휘둘리는 것이 아닌지... 그렇지 않으리라 기대해본다.

    Posted by 장현춘

    이랜드 시스템 황용호 아키텍트 팀장이 Spring.NET, NHibernate, SVN, NUnit, NAnt, Log4net 등 다양한 오픈 소스를 적용하여 Formular# 이라는 표준 개발 프레임웍을 만들어 고객사에 적용하면서 느낀 점을 블로터닷넷과의 인터뷰에서 밝히고 있다. 몇 가지 음미해볼 만한 부분을 인용해보면...

    오픈소스 기반 프레임워크를 도입하기 전에는 관련 프레임워크에 대한 교육이 쉽지 않았는데, 이미 전세계적으로 알려진 제품이다보니 이 부분도 상당히 수월하게 진행됐다

    오픈소스 프레임워크를 활용하면서 고객들과 더욱 대화를 많이 할 수 있고, 전체 아키텍처 구현에 더 많은 시간을 투자할 수 있게 된 것이 가장 큰 이점이라고

    기술적인 이슈를 처리하는 것에 온 심혈을 기울였던 기존 프로젝트에 비해서 현업의 요구가 정확히 무엇인지 요구가 올바른 것인지 검토하고 앞으로 구현될 시스템이 어떨지 사전에 가시화시키고 효과를 미리 검증하는 것에 투자하는 것으로 자연스럽게 바뀌지 않을까요

    인터뷰 내용을 살펴보면 개발팀을 이끌고 있는 입장에서 자체 개발했던 프레임웍 개발자가 떠남으로 인한 업그레이드 문제며, 고객의 비지니스에 집중하기 보다는 개발 이슈 해결에 집중해야 했던 지난날의 개발 모습 등이 눈에 선하게 다가온다.

    전체 인터뷰 내용은 아래 링크에서 직접 확인하시길...

    [오픈소스를말한다]⑫이랜드 황용호 팀장, “유연한 아키텍처 설계에 집중”

    Posted by 장현춘

    ASP.NET MVC 프레임웍의 출시가 임박한 가운데, ASP.NET MVC Release Candidate 2가 출시되었다. RC1에 있었던 몇 가지 버그가 수정되었고 새 기능이 추가되었다. 변경된 것으로는 ASP.NET MVC RC 2 설치시에 .NET Framework 3.5 SP1을 요구한다. 하지만 실행시 런타임 자체는 SP1에 대한 dependency가 없기 때문에 binary 배포할 경우 SP1 없는 .NET Framework 3.5 설치하에서도 동작한다. 또한 쿠키를 통한 사기 방지를 위해 쿠키에 쿠키 경로를 포함시킬 수 있으며, 포함된 jQuery의 버전이 1.2.6 에서  1.3.1 로 변경되었다. DefaultModelBinder의 validation 관련 메시지가 현지화될 수 있게 변경되었고, 에러 메시지 출력시 헤더 역할을 하는 메시지를 원하는 내용으로 채울 수 있도록 하는 새로운 ValidationSummary 메소드가 overload되었다.

    아래 싸이트에서 다운로드 받을 수 있다.
    http://www.microsoft.com/downloads/details.aspx?FamilyID=ee4b2e97-8a72-449a-82d2-2f720d421031&displaylang=en

     

    Bug Fixes since RC 1

    ·         The DropDownList helper no longer throws an exception if a null argument is passed for selectList.

    ·         In the Web.config file, the LogOn URL value in the authentication section has been corrected.

    ·         Code nuggets that are direct children of the head element do not cause an exception if the runat="server" attribute is added to them.

    ·         The CheckBox and RadioButton helpers now restore current values from model state.

    ·         The Default.aspx page that is included in the default project template now works correctly with output caching. Note that this file is not needed if the application is running under IIS 7 Integrated mode.

    Upgrading from the RC 1 Release to Release Candidate 2

    ·         Update the references to the following assemblies to point to the RC 2 versions:

               System.Web.Mvc.dll

         By default, this assembly is located in the following folder:

              %ProgramFiles%\Microsoft ASP.NET\ASP.NET MVC 1.0 RC2\Assemblies

    ·         After you have made this change, compile your application and resolve any compilation errors.
    Posted by 장현춘

    지난 포스팅에서는 프레임웍 기반 개발이란 무엇인가 살펴보고, 닷넷 개발 생태계 측면에서 오픈 소스 기반의 프레임웍이 제공하는 가치에 대해 알아 보았다. 또한 이후 포스팅에서는 프레임웍 기반 개발의 장점과 적용시 유의사항에 대해 살펴보았다.

    Framework-based Development – 개념
    Framework-based Development – 적용
    Framework-based Development – 종류
    Framework-based Development - 오픈 소스 적용 사례

    이번 시간에는 프레임웍 기반 개발시 적용할 수 있는 오픈 및 오픈 소스 프레임웍들에는 어떠한 것들이 있는지 살펴보기로 한다.

    통상적인 웹 기반 애플리케이션을 개발할 경우 Presentation-Business-Data Tier라는, 일반적으로 얘기하는 3 Tier 아키텍처를 갖게 되는데, 각 Tier에서 사용할 수 있는 범용 개발 프레임웍으로는 아래와 같은 것들이 있다. (필자는 logical은 layer, physical은 tier라는 구분을 좋아하지 않는다. 인접하는 컴포넌트 사이에 수평적으로 서비스를 제공하고 주고 받는 사이를 tier, 한 tier내에서 수직적인 구조를 layer라고 구분하는 것을 좋아한다.)

    전통적으로 프리젠테이션 티어 구현 기술로는 ASP.NET이 있었고 이는 널리 알려진 바대로 Page Controller를 구현한 일종의 MVC 프레임웍이다. 프리젠테이션 티어의 가장 큰 관심사는 사용자의 요구를 어떻게 효과적으로 처리할 것인가에 관한 것으로 MVC가 그 핵심이다. 엔터프라이즈 솔루션 아키텍처 디자인 패턴이라는 p&p가 제공하는 가이드에 Page Controller의 최상위 클래스가 복잡한 분기문으로 가득차게 되면 Front Controller를 고민하라고 했듯이, 일반적으로 Front Controller는 Page Controller 보다 좀더 복잡한 애플리케이션 구축에 활용하는 패턴이다. Front Controller 패턴으로 구현한 ASP.NET 기반의 MVC 프레임웍이 바로 ASP.NET MVC 프레임웍이며 현재 베타상태이다. ASP.NET MVC 이전에 시장에는 Castle Project에서 오픈 소스 기반으로 MonoRail을 만들어 배포하고 있었으며, 자바에서 포팅된 Maverick.NET이라는 것도 있었다. 그외 MVC의 View 부분을 치환할 수 있는 다양한 엔진들이 등장하였는데, 그 중에는 자바 template engine인 Velocity의 닷넷 버전인 NVelocity, MonoRail을 위한 View Engine인 Brail, Rails의 view engine으로 널리 쓰이는 Haml의 닷넷 버전인 NHaml 등이 있다. 향후 프리젠테이션 티어의 구현 기술로 가장 주목을 받을 것은 ASP.NET MVC임에는 이론의 여지가 없어 보인다.

    비지니스 티어의 가장 큰 관심사는 객체 라이프싸이클 관리이다. 사용자의 요구에 대해서 비지니스 도메인을 구현한 객체들을 얼마나 효과적으로 생성하고 관리하며, 프레임웍과 도메인 구현 엔티티 사이의 의존성을 줄여 향후 유지보수 측면에서 IT 부서의 부담을 줄여 줄 수 있는지가 관심사이며 여기에 핵심 키워드는 Dependency Injection, AOP 라 볼 수 있다. 전통적으로 일반 닷넷 객체 (PONO – Plain Old NET Object)로 원하는 비지니스 기능을 구현했으며 이때는 닷넷 프레임웍이 제공하는 기본적인 객체 생성 및 GC 매커니즘에 의존하고 개발자의 스킬에 의해 메모리 관리 등을 처리하였다. 하지만, 근래에 DI 기능을 기본으로 탑재한 컨테이너들이 수도 없이 출현하였고 가장 대표적인 것들이 위 그림에 나와 있다. Unity는 마이크로소프트 P&P 팀이 제공하는 것으로 Enterprise Library의 객체 라이프싸이클 관리 기능을 제공하는 ObjectBuilder의 Wrapper 클래스들로 구현되어 있으며 현재 Silverlight 지원하는 버전까지 제공되고 있다. 그 밖에 자바 진영의 대표적인 DI 컨테이너인 Spring이 포팅된 Spring.NET이 많은 개발자의 관심을 끌고 있으며 실제로 국내외 닷넷 프로젝트에 적극 활용되고 있다. DI 기본 기능에 프리젠테이션 티어와 데이타 티어의 각종 프레임웍에 대한 편리한 Wrapper 기능을 제공하는 것으로 정평이 나 있다. StructureMap은 Jeremy D. Miller가  만들어 유지보수하고 있으며 닷넷 진영의 가장 오래된 DI 컨테이너이다. Windsor 컨테이너는 Castle Project의 산물이며, NInject는 빠른 DI 기능 제공을 내세우며 근래에 등장한 컨테이너로서 실버라이트 및 .NET Compact Framework 지원 버전까지 제공한다. 많은 비지니스 티어 관련 프레임웍 중에서 전 세계적으로 가장 많이 사용되고 있는 것은 StructureMap으로 알려져 있으나 향후에는 Unity 아니면 Spring.NET이 대세가 되지 않을까하고 조심스럽게 점쳐 본다. 이유는 Enterprise Library의 DI 기능은 위에서 언급된 DI 컨테이너들 거의 모두를 사용하여 제공될 수 있으나 기본적으로는 Unity가 포함되어 있다. 따라서 이전부터 Enterprise Library를 써 오면서 ObjectBuilder에 익숙한 사람들은 많은 고민없이 Unity를 선택할 것으로 판단된다. Unity (Objectbuilder)는 시장에서 어느 정도 검증되었고 피드백도 좋다. Spring.NET은 자바 진영의 de-facto standard DI 컨테이너이며 이의 명성을 바탕으로 닷넷 진영에서도 빠르게 세를 넓히고 있다.

    데이터 티어는 기본적으로 ORM (Object-Relational Mapping)을 제공하며 이 티어에는 Object와 RDB 사이의 Impedence Mismatch를 해결하는 다양한 기술들이 제공되고 있다. 전통적으로는 ADO.NET API를 사용하여 DAO 패턴을 적용하여 ORM을 처리하였고 지금도 가장 많이 쓰이고 있는 방식이 아닐까 생각된다. .NET Framework 3.5부터 등장한 LINQ (to SQL, Entity, Object, XML)는 개발자들로 하여금 SQL에 대한 두려움을 어느 정도 상쇄시켜 줄 수 있는 획기적인 DSL 방식의 해결책이다. Entity Framework은 마이크로소프트가 내놓은 진정한 의미의 ORM이라고 할 수 있으며 객체와 데이터베이스 테이블 사이의 다대다 매핑을 지원하며 둘 사이에 의존성을 갖지 않고 독자적으로 변경을 가할 수 있도록 고안된 추상화 레벨을 한 단계 끌어올린 ORM이다. NHibernate와 iBATIS.net은 자바 진영의 ORM 시장을 양분하고 있는 오픈 소스 기반의 대표적인 ORM 툴이며 이것들의 닷넷 버전이다. NHibernate와 iBATIS.net은 현재 국내외 프로젝트에서 주목을 받으며 적용된 사례가 있으며, 각각 고유한 장점이 있기에 적용하고자 하는 필요에 가장 잘 부합하는 것을 선택하는 것이 필요하다. SubSonic은 Rob Coney가 만든 오픈 소스 ORM으로 Rails의 scaffolding 기능까지 제공하고 있다. 또한 SubSonic은 .NET Framework 3.5 SP1에서 제공되는 ASP.NET Dynamic Data에 Scaffolding 기능을 제공하며 .NET Framework에 포함되었다. 하지만 여전히 SubSonic은 오픈 소스로 제공되고 있다. ActiveRecord는 역시 Castle Project의 ORM 관련 산물이다. ORM  툴들은 여기 예시된 것 이외에 상용을 포함하여 훨씬 많은 것들이 시장에 나와 있으며, 이 많은 프레임웍 중에서 LINQ, NHibernate, iBATIS.NET이 가장 주목을 많이 받을 것으로 기대된다. LINQ to NHibernate도 이미 시장에 나와 있듯이 핵심 기능은 NHibernate나 iBATIS.net을 쓰되 개발자 인터페이스 부분은 LINQ가 담당할 가능성도 있다.

    참고로, Castle Project를 진행했던 Hamilton Verissimo와 SubSonic을 만든 Rob Conery 모두 마이크로소프트 직원이 되었지만, 현재 이들은 여전히 오픈 소스 프레임웍 개발에 전념하고 있다.

    정리하면 다음과 같은 조합이 가장 현실적인 대안이 되지 않을까 한다.
    ASP.NET MVC + { Unity, Spring.NET } + { LINQ, NHibernate, iBATIS.net }

    이들 프레임웍들은 서로의 존재를 모르고 시장에 나온 경우가 많다. 따라서 이들 프레임웍들을 효과적으로 연동하기 위한 약간의 수고 필요한데, 대부분의 경우 특히 유명한 프레임웍들은 서로에 대해 연동하는 Wrapper를 자체적으로 제공하거나 MVCContrib과 같이 별도의 프로젝트에서 인접 티어의 프레임웍 연동 기능을 제공하고 있다. 예를 들면, MVCContrib은 ASP.NET MVC와 인접한 다양한 DI 컨테이너들 즉, Unity, Spring.NET, Windsor 등에 대한 연동 모듈을 제공하고 있으며, Spring.NET 자체적으로는 NHibernate에 대한 Wrapper를 제공하고 있다.

    시장에서 가장 많이 사용하는 범용 프레임웍들을 조합하여 하나의 예로서 Billy McCafferty가 제시하는 것으로 Sharp Architecture가 있다.

    그림에서 보듯이 Billy는 다양한 시도를 진행했다. 처음에 ASP.NET MVC + Spring.NET + NHibernate의 조합을 제시했다가 DI 기능만을 위해 Spring.NET을 쓰는 것이 비효율적이라 생각되어 Spring.NET을 빼고 DI 기능을 손수 PONO 형태로 구현했었다. 이후 NInject라는 가벼운 DI 컨테이너를 다시 도입한 빌드를 선보였고, 근래에는 NInject 대신에 Windsor 컨테이너를 조합한 빌드를 제시하고 있다. 따라서 Sharp Architecture 싸이트에 가보면 다양한 조합의 빌드를 다운받아 테스트해 볼 수 있다.

    여기에서 언급된 다양한 프레임웍 및 관련 자료에 대한 링크는 다음과 같다.

    마이크로소프트 제공

    Patterns & Practices

    http://www.microsoft.com/practices

    CodePlex

    http://www.codeplex.com

    ASP.NET MVC

    http://www.asp.net/mvc

    ASP.NET MVC Contrib

    http://www.codeplex.com/MVCContrib

    Scott Guthrie Blog

    http://weblogs.asp.net/scottgu/

    Unity Application Block

    http://www.codeplex.com/unity

    Enterprise Library

    http://www.codeplex.com/entlib

     오픈 소스 프레임워크

    Sharp Architecture

    http://code.google.com/p/sharp-architecture/

    Castle Project (MonoRail, Windsor, ActiveRecord)

    http://www.castleproject.org/

    Ninject (DI)

    http://ninject.org

    Spring.NET (DI)

    http://springframework.net

    StructureMap (DI)

    http://structuremap.sourceforge.net/Default.htm

    S2Container.NET (DI)

    http://s2container.net.seasar.org/en/index.html

    autofac (DI)

    http://code.google.com/p/autofac/

    compactcontainer (DI for compact framework)

    http://code.google.com/p/compactcontainer/

    LinFu (DI)

    http://code.google.com/p/linfu/

    NHibernate (ORM)

    http://www.hibernate.org/343.html

    iBATIS.NET (ORM)

    http://ibatis.apache.org/

    SubSonic (ORM)

    http://subsonicproject.com

    Posted by 장현춘

    지난 포스팅에서는 프레임웍 기반 개발이라는 것이 개발자 영역에서의 자연스런 진화의 산물이며, 시장에 널려 있는 수많은 프레임웍 가운데 자사의 현실에 적합한 프레임웍들의 조합을 통해 프로젝트 전체를 관통하는 뼈대를 만들어 좀 더 나은 애플리케이션을 만드는 기법임을 알 수 있었다. 또한 이때 조합의 대상이 될 즉, candidate 프레임웍들로는 가급적 닷넷 개발 생태계의 산물인 오픈 프레임웍을 선정함이 바람직함을 얘기한 바 있다.

    Framework-based Development – 개념
    Framework-based Development – 적용
    Framework-based Development – 종류
    Framework-based Development - 오픈 소스 적용 사례

    이번 시간에는 프레임웍 기반 개발이라는 것이 일반적으로 어떠한 장점이 있는지, 그러한 것을 적용할 때 어떤 방법을 쓰는 것이 좋은지 살펴보도록 하자.

    개발 프레임웍을 프로젝트에 도입하는 순간 기본적으로 프로젝트의 복잡성은 증가한다. 낯선 프레임웍에 대한 두려움과 새롭게 배워야하는 부담이 개발자들을 짓누르기도 한다. 라이브러리성 프레임웍의 경우 단순히 사용 방식을 익혀야 하는 수고가 더 든다는 정도에 그칠 수 있지만, 개발 프레임웍 즉, 애플리케이션의 컨트롤을 좌우하는 소위 Dependency Injection 등을 제공하는 컨테이너 형태의 프레임웍을 도입하게 되면 문제는 훨씬 복잡한 양상을 띈다. 늘 익숙한 방식의 직접 호출이 아닌 중간에 프레임웍이 위치하여 간접 호출이 일어난다는 것은 기본이고, 라이브러리를 사용할 경우 내가 주체가 되어 예측가능한 시간에 객체를 생성하고 예측가능한 방식으로 객체의 라이프싸이클을 관리할 수 있는 것과는 달리, DI 기능의 프레임웍을 도입할 경우 주객이 전도된다. 이것을 Inversion of Control이라고 부른다. 즉, 일단 DI 컨테이너로 넘어간 컨트롤은 내가 짠 코드와 무관하게 잘 짜여진 프레임웍의 규칙에 의거하여 진행하며 내가 짠 코드는 프레임웍이 정한 룰에 의해 필요시 불리어 객체가 생성되고 관리되며 소멸된다. 흔히 말하는 라이브러리성 프레임웍이 아닌 개발 프레임웍들을 도입하게 되면 일정정도 Inversion of Control이 일어나게 된다. 이 또한 처음 프레임웍을 접할 때 익숙치 않은 경험이 되며 직관적이지 않고 수많은 설정과 장치들을 파악하는 수고들이 번거롭게 느껴지기도 한다. 이렇듯 언뜻 보기에 프로젝트의 복잡성을 증가시키고 참여 인력들에게 낯선 것에 대한 두려움과 학습의 번거로움을 선사하는 프레임웍을 도입하면 어떠한 장점이 있을까 ?

    오픈 프레임웍의 경우 시장에서 수많은 프로젝트라는 담금질을 거치면서 scalability, managebility, maintainability, performance 등등의 비기능적 요구사항들은 일정수준 이상의 수준에 도달하게 되고, 프레임웍이 제공하는 정형화된 호출 패턴을 준수하게 되어 코드가 일관성 있게 작성 유지되는 장점이 있다. 또한 프로젝트 규모가 커질수록 참여하는 조직이 다양해지고 참여 인력의 기술 수준 또한 다양할 수 밖에 없는데, 이처럼 다양한 수준의 개발자들에게 각종 품질 요소와 관련된 것들을 맡기는 것이 아니라 대부분을 프레임웍에게 맡겨 처리하게 함으로써 일정 수준 이상의 품질을 보장할 수 있게 된다. 반제품화된 프레임웍의 특성상 개발 기간 및 비용을 절감할 수 있으며, 참여 인력의 만족도 또한 증가하게 된다. 언뜻 이해되지 않는 대목일 수도 있으나 처음 프레임웍을 접하고 낯설었지만 개발에 적용하면서 익숙해져 결국 프로젝트가 끝날 무렵에는 이 큰 프로젝트에 시장에서 de-facto standard로 받아들여지는 프레임웍을 적용하여 개발했다는 자신감을 갖게되며, 또한 개인 이력서에도 멋지게 한 줄 올릴 수 있다. 닷넷에서는 아직 낯선 풍경이겠으나 자바 진영의 구인란을 보면 예를 들어, Struts+Spring+Hibernate 경험자 우대 등의 구체적인 프레임웍 경험을 중시하는 구인 광고를 흔히 볼 수 있다.

    잠시 쉬어가는 코너로 오픈 프레임웍에 대해 거부감이 있는 독자를 위해 예전에 겪었던 경험을 잠시 써 보면...
    대략 4년 전쯤, 대법원이 국내 굴지의 SI 업체가 개발중이었던 시스템에 대해 Architecture Assessment를 한국 썬에 요청한 적이 있었다. 썬은 호주의 아키텍트 두 명과 국내 컨설턴트 두명(그중 하나 필자)을 파견하여 SI 업체가 개발 중인 시스템을 분석하고 참여자들과의 인터뷰를 통해 보고서를 제출하였다. 많은 지적 사항 가운데 프레임웍 관련된 부분만을 언급하면...
    SI 업체가 만들어 유지 보수하며 다년간 많은 프로젝트에서 사용하고 있는 자체 개발 프레임웍을 쓰지 말고 가급적 오픈 소스 기반의 프레임웍을 쓸 것을 추천하였다. 아이러니한 것은 그 당시 썬은 자사 상용 프레임웍인 Sun One Application Framework (“JATO”)를 팔고 있을 때였는데, 썬 직원이 아무런 주저없이 자사 솔루션이 아닌 오픈 소스 프레임웍을 추천하고 돌아간 것이다.....

    시장에서 널리 쓰이는 프레임웍들을 조합하여 프로젝트의 전체 뼈대를 만들고자 할 경우 어떤 접근 방식을 취하는 것이 좋을까 ? 프로젝트가 시작되면 기본적으로 통합팀을 중심으로 각종 가이드가 만들어지고 참여 인력에 대한 각종 교육이 진행된다. 가령 단순하게는 naming convetion에서 방법론이라든지 신기술이라든지 적용할 프레임웍에 이르기까지...
    낯설지만 시장에서 각광받는 프레임웍들을 조합하여 진행할 때, 참여 인력 모두가 프레임웍에 대해 전문가가 될 필요는 없다. 아니 그럴 수도 없다. 많은 경우 함께 공부해가면서 책에 나와 있는 예제 중심으로 코드를 만드는데, 시일도 오래 걸리거니와 자칫 사소한(?) 것에 발목잡혀 낭패를 볼 수도 있다. 추천하는 것은 가급적 프로젝트 진행하는 팀 내에는 해당 프레임웍에 대한 전문가가 최소 한명이 있어야 한다. 이유는 프레임웍이라는 것이 개발 생태계에서 진화를 하면서 소위 “By Design”이라는 형태의 제약이나 의도된 설계가 있기 마련이다. 참여 인력 모두가 이런 것까지 학습할 시간적 여유가 없으며 누군가는 이러한 것들을 고려하여 개발자들이 사용할 가이드를 만들어 배포하여야 한다. 개발자에게 배포되는 가이드는 많은 것들을 고려하여 작성되었겠지만 실제 개발자에게 전달할 메시지는 아주 단순한 형태이어야 한다. 가령 개발 3단계, 첫째 맡고 있는 Use Case에서 추출한 명사로부터 대문자로 시작하는 클래스를 만들되 통합팀에서 배포한 BaseXXX를 상속받아 작성하고 둘째 반드시 XXX() 메소드를 오버라이드한다. 셋째 컴파일 한 후 특정 위치에 복사한 후 주어진 설정 파일에 등록하면 된다. 사용할 수 있는 소스 코드 탬플릿 양식과 샘플은 형상 관리 도구의 특정 branch에 있으니 참고하라는 식의... 물론 개발자들이 개발 과정에서의 갖게 되는 의문을 풀어주고 이해를 돕기위해 아키텍처 문서나 프레임웍 동작 원리 등을 제공하여 프로젝트를 거치면서 개발자들의 자연스런 성장을 돕는 것도 필요하다.

    잠시 또 사례를 들면, 프레임웍에 대한 전문 인력이 없이 개발자들이 학습과 개발을 병행하며 프로젝트를 진행할때 발생했던 사례로써 역시 굴지의 국내 또 다른 SI 업체의 자바 솔루션 개발 경우이다.
    그룹사 전체에 특정 LOB 애플리케이션을 공급하는 SI 업체는 새 버전에 이전과 달리 Struts이라는 자바 진영의 그 당시 de-facto standard로 통했던, 현재에도 가장 많이 쓰이는 MVC 프레임웍이기도 한 프레임웍을 도입하기로 하고 참여 인력 내에서 책을 구입하여 개발과 학습을 병행하였는데, 아키텍처 자문을 해주는 과정에서 한가지 단순하지만 중요한 실수를 발견할 수 있었다. Struts이 관리(?)되고 있는 Apache 재단의 홈페이지에도 나와 있는 아주 단순한 원칙, “Action” 클래스는 같은 URI 요청에 대해 singleton으로 동작한다는 사실을 모르고 클래스를 작성하였던 것이다. 하여 개인이 테스트 할때는 별 탈이 없었지만 동시에 요청이 들어오면 thread-safe하지 않은 행동을 보이고 있었던 것.... Struts의 히스토리를 보면 원래는 singleton이 아니었는데 중간에 왜 singleton으로 바꾸게 되었는지 설명해 놓은 대목이 있다. 이런 것을 모든 개발자가 알 필요는 없지만 최소한 한 사람 누군가는 알고 이를 고려한 가이드나 설계가 제시되고 이를 통해 쓸데없이 시간과 정력이 낭비되는 것을 막아야 한다.

    이런 유사한 사례는 신기술 혹은 새로운 프레임웍을 적용할 경우 흔히 볼 수 있다.
    다음 시간에는 현재 닷넷 개발 생태계내에서 만들어지고 발전되어 가고 있는 오픈 프레임웍들을 살펴보고 어떠한 것들이 시장에서 각광을 받고 있는지 함께 알아보는 시간이 되었으면 한다.

    또한 참고로 예전 포스팅에서 정리했던 닷넷 개발 프레임웍 리스트를 보는 것도 도움이 될 것으로 생각한다.

    Posted by 장현춘

    프레임웍 기반 개발이라는 것은 말 그대로 엔터프라이즈 애플리케이션을 개발함에 있어서 기존에 만들어진 프레임웍의 조합을 통해 좀 더 빼르고 견고하게 원하는 결과물을 만들어 내는 것을 말하며, 이는 어느 특정 벤더의 개발 방법론도 아니고 개발 영역에서 자연스럽게 발전하여 체득된 개발 방식이다. SI 경험이 많은 대부분의 기업에게는 기업용 애플리케이션 개발에 있어서 경험으로 부터 다듬어져 프레임웍의 형태를 띄는 것들을 가지고 있다. 추상화 혹은 모듈화 정도의 차이가 있을 뿐, 혹은 대외적으로 홍보하는 이름이 있고 없을 뿐 대부분의 개발이 프레임웍 기반으로 진행되고 있다고 봐도 무방하다.

    향후 몇 번에 걸쳐 프레임웍 기반 개발에 대해 살펴보기로 하자

    Framework-based Development – 개념
    Framework-based Development – 적용
    Framework-based Development – 종류
    Framework-based Development - 오픈 소스 적용 사례

    이처럼 많은 개발사 혹은 개발자들이 경험으로부터 선호하게 되는 프레임웍이라 것은 선조 프로그래머들의 지혜를 재활용하는 많은 방법 중에서 가장 개발자에게 직관적이고 현실적인 재사용 수단이다. 즉, 남들이 만들어 시장에서 다양한 곳에 적용되어 능력을 검증 받은 코드셋을 가져다 내 환경에, 나의 프로젝트에 맞게 약간의 변형을 가하고 설정을 변경하여 재사용할 수 있는 잘 만들어진 클래스 집합인 것이다. 프레임웍을 분류하는 방식은 프레임웍의 정의만큼이나 다양하나 일반적으로 블랙 박스 vs 화이트 박스 혹은 라이브러리성 vs 개발 프레임웍(컨트롤) 혹은 아주 간단하고 자주 쓰이는 오픈 (오픈 소스) vs 상용 프레임웍 등이 있다.

    프레임웍 기반 개발이라는 것은 상용이든 오픈이든 용도에 맞는 가장 적절한 프레임웍들의 조합을 통해 전체 프로젝트를 관통하여 사용될 뼈대를 완성하고 개발자들로 하여금 비지니스 로직을 구현하여 이 뼈대가 제시하는 Contract에 맞게끔 개발하도록 만드는 정형화된 개발 방식이다. 이렇게 시장에서 검증된 프레임웍들의 조합을 통해 자연스럽게 흔히 얘기하는 비기능적 요구사항 (소위 QoS 요소)들을 달성하고 개발자들은 주어진 도메인에 집중하여 고객에게 전달할 가치 (기능적 요구 사항 포함)를 창출하도록 만드는 것이다. 이를 통해 개발자들의 창의성과 생산성을 기반 프레임웍 개발에 쓰여 낭비하지 않도록 하며 좀 더 나은 고객 가치를 전달하는데 사용케하자는 것이다.

    여기서 생각해 볼 문제는 과연 어떤 프레임웍들을 조합의 대상으로 삼을 것인가 하는 점이다. 이 점에서 많은 부분 동의하지 못하는 분들도 있을 것 같은데, 필자는 가급적 오픈 (혹은 오픈 소스) 기반의 범용 개발 프레임웍들을 조합하길 권장하는 바이다. 흔히 말하는 범용 개발 프레임웍은 말 그대로 도메인에 특화된 로직을 품고 있지 않아서 대부분의 프로젝트에 쓰일 수 있는 기본 기능을 담고 있는 것들이다. 가령 로깅, 에러 처리등의 라이브러리들을 포함하여 객체 라이프 싸이클 관리, 모니터링 혹은 다른 레이어와의 인터페이스 모듈 등등 모든 프로젝트에서 항상 고민하는 것들이 포함된다. 세상에는 이미 나 혹은 내가 속한 팀, 더 나아가 우리 회사가 만들어 자랑스럽게 내세우는 프레임웍 보다 더 훨씬 더 잘 만들어 공개되어 우리 회사가 10년 아니 우리 회사가 망할때 까지 수행해도 다 못할 만큼의 전세계 수많은 프로젝트에서 다양한 환경에서 검증되어 발전해가는 즉, 닷넷의 개발 생태계 내에서 태어나 성장하는 뛰어난 범용 개발 프레임웍들이 널려 있다. 이제는 이러한 것들을 함께 공유하고 이러한 개발 생태계내에 우리도 일원으로 참여하여 생태계를 키우고 그로 인한 열매를 함께 향유하는 것이 필요하다.

    오해하지 말 것은 필자가 범용 개발 프레임웍이라고 칭하는 부분이다. 도메인에 특화된 비지니스 프레임웍들을 여전히 상용으로 판매되고 있다. 가령 금융 패키지 혹은 코어 뱅킹, 제조 패키지 등등 도메인에 특화되어 있기에 닷넷에 대한 개발 노하우가 있다고 누구나 만들 수 있는 것도 아니며 도메인 지식이 풍부해야 진입할 수 있는 영역이기에 개발 생태계가 관장하기에는 아직 닷넷 개발 생태계가 성장하기 못한 면이 있다. 하지만 마음만 먹으면 누구나 만들 수 있는 범용 개발 프레임웍은 사정이 다르다. 전세계가 유사한 기능을 하는 비슷비슷한 프레임웍이 나타나는 이유는 간단하다. “난 쟤들 거 이런 이런 점이 맘에 안들어...” 이거다. 이렇게 만들어진 것이 대중의 사랑을 받게 되면 개발 프레임웍에 있어 de-facto standard로 자리잡아 칭송을 받게 되는 것이다.

    고객이 입장에서 보면 오픈을 써야하는 이유는 더 극명하다. 벤더 종속적인 프레임웍을 도입하였을 경우 기반이 되는 .NET의 발전에 맞추어 유지보수해야 하는 문제며, 소스 코드를 포함한 소유권 문제 등도 있고, 프레임웍 개발사가 증명할 수 있는 각종 QoS 수준과 전세계 닷넷 개발 생태계가 증명할 수 있는 수준과의 신뢰성 등 고객은 이미 오픈 혹은 오픈 소스에 대해 많은 것을 알고 있다. 개발자들의 자유로운 접근과 사용, 그리고 그 과정에서 주고 받는 Q&A 및 피드백을 통해 오픈 프레임웍은 자연스럽게 생태계속에 편입되어 발전하게 되는 것이다.

    다음 시간에는 현재 우리가 사용할 수 있는 프레임웍들에는 어떤 것이 있고 어떤 점을 고려하여 선정하여야 하는지 더 나아가 적용할 때 고민해야 할 부분등에 대해 함께 알아보도록 하자.

    Posted by 장현춘

    Composite Application은 다양한 리소스로부터 얻은 각기 다른 정보를 최종 사용자에게 가장 바람직한 방식으로, 사용자가 원하는 방식으로 전달하기 위해 화면 구성을 모듈화하고 사용자의 권한과 역할에 따라 화면 구성 및 화면 전환을 달리할 수 있도록 하는 등 사용자 경험을 최적화시키기 위한 만들어지는 애플리케이션이다. 몇 년전까지는 Composite Smart Client라는 이름으로 많은 기업들에 제공되던 방식이기도 하다.
    image

    현재 Composite Application을 쉽게 구축할 수 있도록 마이크로소프트가 제공하는 Application Block들은 다음과 같다.
    -. Composite UI Application Block (CAB) - Windows Form 기반의 composite application을 만들때 유용하다.
    -. Smart Client Software Factory (SCSF) - CAB을 핵심으로 관련 application block들을 조합하고 각종 아키텍처 및 개발에 관련된 가이드 및 레시피, How-to 등을 제공하며 Visual Studio에 템플릿 형태로 제공되어 역시 Windows Form 기반의 composite application을 쉽게 개발할 수 있다.
    -. Composite Application Guidance for WPF - CAB의 아키텍처적인 장점 및 동작 방식의 장점을 수용하였지만, WPF 기반에서 바닥부터 다시 만든 WPF 기반 composite application 개발 프레임웍이다.

    Composite Application Guidance for WPF는 미국 시간 기준 7월 4일 정식 발표되며, 아래 싸이트에서 정보를 확인할 수 있다.
    MSDN : http://msdn.microsoft.com/compositewpf
    (use http://msdn.microsoft.com/en-us/library/cc707819.aspx for now)
    Community : http://www.codeplex.com/compositewpf

    이번에 출시되는 Composite Application Guidance for WPF에는 다음과 같은 유용한 자산이 담겨 있다.
    -. Stock Trader Reference Implemtation
    -. Composite Application Library for WPF
    -. Quick Starts (4개 샘플)
    -. Hands on Lab (1개)
    -. 문서 (300페이지 이상)
       -. Composite Baseline Architecture
       -. UI Designer Guidance
       -. Design Concepts (3가지)
       -. Technical Concepts (8가지)
       -. Patterns (6가지) + Patterns Overview
       -. How-to (20가지)

    Acropolis의 중도 포기 이후, CAB과 같이 확장성 있고 모듈화가 잘 되어 있지만, Windows Form 기반이 아닌 WPF 기반 composite UI application block을 원하던 개발자들에게는 그간의 갈증을 해소시켜줄 수 있는 단비가 아닐까 싶다.

    참고로 현재까지 나와 있는 Composite Application 구축에 활용할 수 있는 프레임웍을 용도에 따라 구분하면 다음과 같다.
    image

    Posted by 장현춘

    프레임웍, 특히 시장에서 널리 사용할 수 있는 오픈 소스 기반의 프레임웍에 대한 스터디 모임이 시작됐다. 마이크로소프트 에반젤리트 일부, 외부 MVP 및 재야의 숨은 고수들과 함께 프레임웍에 대해 함께  모여 공부하고 이를 외부에 공개하여 프레임웍, 특히 오픈 소스 프레임웍에 대한 붐을 닷넷 개발자 사이에 확산하기 위한 시도이다.
    스터디 모임은 비공개로 제한된 인원으로 시작하며, 발표자료 및 발표 동영상은 아래 싸이트에 게시되어 모두가 자유롭게 접근하여 배포할 수 있게 할 예정이다.

    프레임웍 스터디 까페

    첫 스터디 모임은 6월 30일 예정되어 있으며 주제는 시장에서 한창 인기를 얻고 있는 ASP.NET MVC + Spring.NET + NHibernate 조합인 Sharp Architecture이다. 이를 기점으로 활성화될 것으로 기대한다.

    Posted by 장현춘

    한국마이크로소프트의 닷넷 파트너인 엔소아 컨설팅에서는 닷넷 오픈 소스 프레임웍의 활성화를 위해 "Spring.NET 프레임웍 활용 가이드"를  만들고 있으며 현재까지 완성된 v0.2 를 공개하였다. 닷넷에서, 특히 국내 닷넷 프로젝트에서 관심이 점점 증가하고 있으나 쉽게 접하여 활용할 수 있는 가이드 형태의 문서가 많지 않은 현실에서 엔소아 컨설팅의 이러한 시도에 많은 박수를 보내고 싶다.

    엔소아 컨설팅에서 작성중인 "Spring.NET 프레임웍 활용 가이드"는 여기서 다운로드 받을 수 있다.
    ==> 다운로드

    Posted by 장현춘