이미 Spring.NET이 기업형 애플리케이션에 적용되고 있다는 얘기도 가끔 듣고 있다. 그러나 달봉이가 직접 POC( Proof Of Concept) 애플리케이션을 하나 만들어서 Spring.NET이 기업에 어떻게 적용될 수 있는지 나름대로 검토를 해 보고자 한다.

달봉이가 만들 애플리케이션은 흔히 현장에서 사용하고 있는 3 티어 구조를 고려한다. 그리고 사용될 주요 기술은 다음과 같다.

최종 개발자가 개발을 할 때 구성하게 될 Visual Studio의 개발 구조는 이렇게 될 것이다. 이 개발 구조의 네임스페이스는 Bong이라는 가상 기업을 상상해서 구성한 것이다.

_Framework 폴더 부분을 보면 두 부분으로 나뉘었다 : 01 Spring, 02 BONGCo

01 SPRING 부분은 달봉이가 Spring.NET을 확장하거나 수정하는 부분이다. 이 부분은 최대한 현장에서 확장/변경될 수 있는 부분을 고려해서 만들어 질 부분이다. 즉 이상적인 모습은 현장에 상관없는 부분이 되어서, 현장에서 소스의 수정이 없는 부분이 되도록 할 것이다. 따라서 이 부분이 현장으로 배포될때는 DLL 형태로 배포될 것이다. 

02 BONGCo라는 폴더에는 앞에서 말한대로 01 SPRING에서 제공하는 프레임워크를 현장에 맞게 확장하는 부분이다. 이 부분은 현장의 공통팀이 맞게 될 것이다.

만약 현장에서 변경요청이 들어왔고, 그 부분을 현장 프레임워크이 커버하지 못한다면, 결국  01 SPRING 부분이 그 변경 요청을 수용할 수 밖에 없다. 이런 경우라면 결국 01 SPRING 부분의 소스도 현장의 요구 사항을 고려해서 수정되어야 한다. 결국 01 SPRING 프레임워크이 현장에서 변경될 수 있는 부분을 최대한 고려해서 만들어져야 한다. 현장마다 변경될 수 있는 부분은 최대한 현장 공통팀이 담당하는 프레임워크에서 처리할 수 있도록 하는 구조로 가야 한다.

예를 들어서 프레임워크에서 사용자 정보를 캐싱하고 있다가 개발자 코드에서 요구하면 프레임워크단에서 제공하는 시나리오는 흔한 요구사항이다. 그러나 그 사용자 정보를 구성하는 항목은 기업마다 다를 수 있다. 이런 경우 01 SPRING에서는 기본적인 사용자 정보(ID )만을 갖는 베이스 클래스 정도만을 가지고 있으면 된다. 그리고 현장의 공통팀에서는 그 베이스 클래스를 상속해서 그 현장에서 요구하는 추가 정보를 가지는 사용자 정보 클래스를 만들면 된다. ( 참고로 현장에서 확장한 사용자 정보클래스를 생성하는 녀석은 01 SPRING에서이다. 01 SPRING에서 어떻게 현장에서 정의한 클래스에 대한 정보를 알 수 있는지는 나중에 언급할 기회가 있을 것이다.)

개발 구조를 다시 보자. 현장 업무 개발팀이 담당해야 하는 부분이 있고, 그리고 Shell이라는 폴더에 BongApp라는 WPF 애플리케이션이 있다. 이 BongApp 애플리케이션은 업무 시스템의 이 시작 프로젝트가 된다. 이 녀석이 시작되면서 메뉴가 로딩되고 화면이 출력되기 시작하는 것이다. 업무 시스템의 엔트리 포인트라 할 수 있다. 

다음 포스트에서는 이 BongApp 프로젝트를 구성하는 작업부터 시작할 것이다. Spring.NET 컨테이너가 기업형 애플리케이션에 적합한지, 어떤 확장이 필요한지를 다룰 것이고, 실제로 애플리케이션의 메뉴 항목들을 컨테이너로 로딩하는 작업등이 있을 것이다.