본문 바로가기

IT 살이

개발 프레임워크 만들기 대장정 17 - Unity 컨테이너 확장예제 II부 지난 포스트에 계속 이어진다. 혹시 지난 포스트를 읽지 않았다면 먼저 체크해보고 이번 포스트를 읽어가길 바란다. 이번 포스트 다 써놓고 보니 무지 길다. 실시간으로 이해를 하면서 쓰는 글이다 보니 이 모양이다. 다시 읽어보고 싶지 않다. 쓰으...틀린곳 또는 이해가 되지 않은 부분 있다면 코멘트 부탁한다. ■ 예제 시나리오 이 예제에서는 두 개의 Unity 컨테이너를 생성한다. 하나는 표준 컨테이너 stdContainer이고 하나는 확장된 기능을 갖는 customContainer이다. stdContainer는 .NET 애플리케이션이 실행되면 자동으로 생성되는 기본 AppDomain으로 어셈블리를 로딩한다. 그리고 customContainer는 기본 AppDomain에서 별도의 AppDomain을 하나 더.. 더보기
개발 프레임워크 만들기 대장정 16 - Unity 컨테이너 확장예제 I부 이제 Unity 컨테이너를 확장하는 방법을 예제를 통해서 알아보자. 이 포스트에서는 어떻게 strategy를 작성하고 어떻게 객체 생성 과정에 끼워넣을 수 있는지를 알아본다. 그러면서 컨테이너 익스텐션에 대해서도 알아본다. 그러나 필자도 생업이 있는지라 예제를 구상하고 구현할 시간이 없다. 대신에 필자도 공부를 할 겸 훌륭하신 분들이 미리 만들어놓은 예제를 분석하는 수준에서 대신하려 한다. 물론 포스트를 그대로 번역만 하지는 않을 것이다. 필자가 필요한 대로 재구성해서 설명하겠다. 이것이 저작권 또는 지적 재산권 뭐 그런거 침해로 봐야 하는지는 모르겠다. 해외 아티클을 번역해주는 블로그도 많은데....만약 그 아티클을 내 생각대로 재해석해서 설명하면 그것은 법적으로 문제가 있나? 문제가 있을 수 있겠다... 더보기
개발 프레임워크 만들기 대장정 15- ObjectBuilder 계속 이번 포스트에서 Unity 컨테이너 확장에 대해서 포스팅을 할까 했는데 아무래도 ObjectBuilder에 대해서 좀 더 설명을 해야 할 것 같다. 코드를 보니까 바로 예제로 들어가기는 무리인듯 하다. 해서 ObjectBuilder가 객체를 생성하는 과정에 대해서 좀 더 자세히 알아보도록 하겠다. 다음은 바로 앞 포스트에서 보인 그림이다. 그림에서는 stage를 "Stage1", "Stage2"로 정의하고 있다. 그리고 각 stage별로 Strategy를 정의하고 있는데, 다음과 같다 : "Strategy1_1","Strategy1_2" 그리고 "Strategy2_1","Strategy2_2". ObjectBuilder의 Strategy는 IBuilderStrategy라는 인터페이스를 구현해야 한다. 이.. 더보기
개발 프레임워크 만들기 대장정 14- Unity 컨테이너 확장? ObjectBuilder ? 이제 Unity 컨테이너가 하는 일에 대해서 굵직한 것은 거의 모두 알아본 것이나 마찬가지다. 타입 매핑 정보를 등록하고 인스턴스를 얻는 API를 컨테이너가 제공해주고 있다는 것을 알았다. 설명하지 않은 API도 더 있긴 하지만. 그리고 config의 스키마에 대해서도 좀 더 자세히 알아봐야 한다. 그러나 구체적인 사항들에 대해서는 개념과 구조 설명을 먼저 마치고 뒤에 일괄적으로 정리해보도록 하겠다. 물론 장담은 못한다 -_-;; 시간이 없거나 힘들면 관련 웹 페이지에 대한 링크로 대신할 수도 있다. 내가 원하는 방법대로 하겠다. 내 블로그니까. 이번 포스트는 다음 링크의 문서들을 참조했다. 이 문서를 처음부터 읽어서 이해가 가는 독자라면 필자의 이번 포스트는 읽지 않아도 되겠다. ObjectBuilde.. 더보기
개발 프레임워크 만들기 대장정 13- Method Call Injection 앞의 Construction Injection과 Setter Property Injection 포스트를 읽었다면, Method Call Injection이라는 것도 메소드를 호출할때 메소드 파라미터를 ? Unity 컨테이너가? 하는 예상을 할 수도 있겠다. 그렇지 않은가? 아님 말고. ● InjectionMethod 어트리뷰트 InjectionMethod 어트리뷰트가 붙은 샘플 코드이다. public class MyObject { public IMyInterface depObjectA; public MyBaseClass depObjectB; [InjectionMethod] public void Initialize(IMyInterface interfaceObj, MyBaseClass baseObj) { d.. 더보기
개발 프레임워크 만들기 대장정 12- Property(setter) Injection 앞의 포스트에서 Unity 컨테이너가 사용하는 dependency injection중에서 constructor injection에 대해서 알아봤다. 이제 두번째로 Property Injection에 대해서 알아보자. ● Dependency 어트리뷰트 사용 property에 dependency injection 표시는 다음과 같다. public class MyObject { private SomeOtherObject _dependentObject; [Dependency] public SomeOtherObject DependentObject { get { return _dependentObject; } set { _dependentObject = value; } } } 코드처럼 Property에 Depend.. 더보기
개발 프레임워크 만들기 대장정 11- Contructor Injection 이전 포스트에서는 Unity 컨테이너는 자신에 등록된 타입들의 메소드(constructor, setter 속성, 일반 메소드)를 호출할때 "특별한 표시"가 있으면 dependency injection 메커니즘을 활성화 시킨다는 말을 했다. 그 특별한 표시는 어트리뷰트를 이용한다. 그 어트리뷰트는 메소드 타입 즉 constructor, setter 속성, 일반 메소드에 따라 다르다. 이제 이 포스트에서는 세개의 표시를 어떻게 하는지 그리고 그 표시들에 따라서 Unity 컨테이너는 어떻게 작동하는지 즉 dependency injection이 뭔지 좀 더 자세히 알아보자. ● Constructor Injection 표시 Constructor가 호출될때 DI 메커니즘을 활성시키는 방법에는 상황에 따라서 두가지가.. 더보기
개발 프레임워크 만들기 대장정 10- Dependency Injection 패턴 이번 포스트에서는 Unity Application Block에서 사용하고 있는 Dependency Injection 패턴에 대해서 알아본다. UAB에서 구현하고 있는 이 패턴에 대해서 잘 이해하면 프레임워크를 만들때 개발자가 해야 할 일을 프레임워크단에서 공통적으로 해결해 줄 수 있는 유연한 방법을 많이 찾을 수있을 것으로 보인다. 프로젝트가 한참 진행되는 도중이라면 새로운 고객의 요구사항을 수용하기가 참 힘들다. 고객은 단순히 메소드에 파라미터 하나만 더 추가해서 빌드하면 되지 않겠는냐는 식으로 간단히 말한다. 그러나 그 간단한 요구사항이 공통팀과 업무 개발자들에게는 쓰나미로 다가오는 경우가 있다. 이런 경우 Dependency Injection 패턴을 잘 활용하면 업무 개발자가 기존 코드의 수정을 하.. 더보기
개발 프레임워크 만들기 대장정 09- Config를 사용한 등록작업 지난 포스트에서 말한 것처럼 이번에는 타입을 시작 프로그램에서 프로그램적으로 컨테이너에 등록했던 작업을 이제 Config로 분리해내는 작업을 하겠다. Unity 컨테이너의 완전한 Config 스키마는 새로운 것이 나올때마다 하나씩 알아보는 것으로 하겠다. 왜냐고? 지금은 필자도 다 모른다는 것이 가장 큰 이유이고 그리고 모든 것을 지금 설명하는 것은 시기상조일것이라는 생각이다. 지난 포스트의 예제의 시작 프로그램의 코드를 다시 한번 더 보자. namespace FSLoggerConsole { class Program { static void Main(string[] args) { // 편의상 이전 로그 파일이 존재하면 삭제한다. 로그가 누적되면 테스트가 방해되잖아. if (System.IO.File.Ex.. 더보기
개발 프레임워크 만들기 대장정 08- 사용자 정보, 애플리케이션 컨텍스트 객체 추가하기 앞 포스트에서 UAB를 사용해서 개발 프레임워크 구조와 유사하게 로깅 프로그램을 구현했다. 프로젝트가 한참 진행되어 개발 진척도는 50%를 넘어가고 있다. 그런데 어느날 고객이 다음과 같이 무심코 내뱉는다. "현재 비즈니스 메소드를 호출할때 로그를 남기고 있는데, 로그로 사용자 아이디와 이름도 남기고 싶습니다". 업무 프로그램에서 고객 아이디와 이름만 로깅 메소드 Write()로 넘겨주면 되겠지하는 생각이 먼저 떠오르는가? 그럼 불쌍한 개발자는 다시 모든 프로그램을 수정해야 하는가? 그리고 다른 프로젝트에서는 사용자의 아이디, 이름뿐만 아니라 부서 정보도 남겨달라고 하면 어떻게 해야 하나. 그때는 프레임워크의 코드를 또 수정해야 하나? 두 번째 문제부터 해결해보자. 이를 위해서 필자는 사용자 정보 클래스.. 더보기
개발 프레임워크 만들기 대장정 07- Hello 프로그램 with UAB 오늘은 UAB(앞으로는 Unity Application Block을 이렇게 줄이겠다)용 Hello 프로그램을 만들어보고자 한다. 앞에서 계속 얘기했던 FSLogger를 구현해서 사이트별 확장 구조의 로깅 프로그램을 만들 것이다. 다음은 Visual Studio.NET의 개발 구조이다. 디렉토리 구조Hello 프로그램치고 너무 복잡한가? "프로레임워크 만들기 대장정"인만큼 Hello 프로그램 구조도 좀 그럴싸하게 만들어서 현장에서 사용하는 것과 유사하게 만들려고 했다. 그러나 뒤에서 코드를 보면 알겠지만 내용은 암것도 없다. 디렉토리 구조를 먼저 설명한다. 솔루션 폴더 "01 DabongFramework"이 개발 프레임워크 관련 프로젝트들을 포함시킬 부분이다. 뒤에 나올 사이트별 확장 프레임워크와 구분할 .. 더보기
개발 프레임워크 만들기 대장정 06- Unity 컨테이너 구조 이제 Unity 컨테이너를 좀 알아보도록 하자. Unity, Unity 컨테이너, Unity Application Block이라는 표현을 섞어서 사용하지만 모두 같은 개념으로 보면 된다. 사실 이런 프레임워크를 다 이해하지는 못해도 사용할 수는 있다는 것은 지금까지 SI 프로젝트에서의 경험을 통해서 보면 잘 알 것이다. 그러나 우리는 프레임워크를 이해하고 만들려는 사람들이다. 따라서 이 구조를 이해할 필요가 있고 결국에는 그 구조를 바탕으로 해서 나름의 생각대로 설계할 수 있길 바란다. 아직 필자도 이 블럭을 모두 살펴본 것은 아니다. 사실은 지금까지의 경험에 의해 아마 그럴 것이다라는 추정을 가지고 확인해가면서 글을 쓰고 있다. -_-;; Unity Application Block을 설치하면 함께 생기.. 더보기
개발 프레임워크 만들기 대장정 05- Unity 컨테이너 소개 이제 Unity Application Block의 Unity에 대해서 알아보도록 하자. 앞에서 설명했던 예제로 다시 돌아가보자. 프레임워크에서는 단지 인터페이스 변수 logger만을 바라보면 되고, 실제 객체에 대한 타입은 외부에서 제공한다고 했다. config 파일을 통해서 제공할 수도 있을 것이고 API를 통해서 프로그램적으로 제공할 수도 있다. 제공된 실제 로거에 대한 타입 정보를 받아서 인스턴스를 생성하는 것은 Unity가 담당한다고 했다. 참고로 Unity가 실제 로거 객체를 생성하는 것에 대해서 잠깐 이야기 하자. Unity가 실제 로거 객체를 생성하는 방법은 new를 사용하는 일반 객체 생성 방법과 조금 다르다. Unity { ... A a = new A(); .... a.Logger = n.. 더보기
개발 프레임워크 만들기 대장정 04- 인터페이스 vs 클래스 더 진행하기 전에 인터페이스와 베이스 클래스의 차이점을 함 생각해보도록 하자. 객체 지향 설계에 익숙하지 않는 개발자는 타입을 설계할때 인터페이스를 사용해야 할지 아니면 클래스를 사용해야 할지를 구분하지 못한다. 이곳에서 나름대로의 기준을 정리해보고자 한다. 상속을 좀 더 자세히 살펴보자. 그럼 상속에는 성격이 좀 다른 상속들이 존재하는 것을 알 수 있다. 어떤 경우는 데이터를 중심으로 해서 상속관계를 생각하는 경우가 있다. 이 경우는 "객체가 내부적으로 어떻게 동작하는가"에 포커스를 두는 것이다. 부모 객체는 자식에 공통적인 데이터를 가지고 있도록 하고 자식 타입에서 자신만의 특별한 데이터를 추가하도록 설계한다면 바로 데이터를 중심의 상속을 설계하고 있는것이다. 그러나 어떤 경우는 기능 중심으로 해서 .. 더보기
개발 프레임워크 만들기 대장정 03- 인터페이스, 상속, 가상 메소드 Unity Applicaion Block에서는 컨테이너라는 개념을 사용하고 있다. 그 컨테이너를 Unity라고 부르고 있다. 컨테이너라는 것이 무엇을 담고(contain), 그것이 뭘 하는지를 생각해보자. 그러나 그 이전에 잠시 다른 문제에 시간을 할애해야 할 것 같다. 처음에는 바로 컨테이너 개념 설명으로 가려 했으나 이것을 설명하기 전에 인터페이스, 베이스 클래스 그리고 상속을 먼저 생각해봐야 할 것 같다. 앞의 포스트에서 확장성 얘기를 하면서 로깅 예를 들었다. 로깅 저장소가 어디냐에 따라서 로깅하는 로직 구현은 달라질 것이다. 데이터베이스에 로깅하는 넘은 DBLogger라고 하고 파일 시스템에 로깅을 하는 넘을 FSLogger라고 이름을 붙이자. DBLogger는 데이터베이스를 연결해서 그곳에 i.. 더보기
개발 프레임워크 만들기 대장정 02- 재사용성 vs. 확장성 개발 프레임워크를 가진 업체가 프로젝트에서 실제로 투입되었을때 고객과의 사이에서 있을 수 있는 갈등중의 하나가 바로 개발 프레임워크의 코드 수정에 대한 것이다. 고객은 프레임워크 코드를 수정해서 자신들이 원하는 기능을 구현해 주길 바란다. 프레임워크 제공 업체에서는 최대한으로 그런 수정을 막아보려 한다. 이 부분은 프레임워크이기 때문에 수정할 수 없다는 것이다. 그러나 프레임워크의 네임스페이스까지도 철저히 수정해주길 원하는 고객을 만나면 끝에 가서는 프레임워크 제공 업체는 어쩔 수 없는 일이다. 물론 이 부분은 두 업체간의 영업적 계약이 어떻게 되었는가에 따라서 이야기가 다분이 달라질 수 있는 측면이 있다. 프로젝트의 재사용성이라는 것을 그런 영업적인 쇼부(쇼부라... 이쯤 되면 이 포스트가 개인적인 것.. 더보기
개발 프레임워크 만들기 대장정 01 - 개발 프레임워크란 SI 프로젝트에 참여하는 개발자들은 대부분 개발 프레임웤에 대한 경험이 있을 것이다. 큰 규모의 프로젝트에서는 나름대로의 개발 프레임워크를 만들어 진행한다. 업무 개발자들이 업무 프로세스를 구현하는데 집중할 수 있도록 잡다한 내용은 모두 블랙 박스로 만들어 놓는 것이다. 개발자들은 블랙박스에서 노출시켜놓은 공개적인 API만을 잘 사용하면 된다는 그런 생각이다. 그러나 프로젝트마다 프레임워크를 설계한 사상이 다르고 구현 또한 달라지기 때문에 업무 개발자들은 프로젝트마다 새로운 프레임워크의 설계와 새로운 API에 익숙해져야만 한다. 업무 개발자들은 피곤한 일이다. 그러다 보니 업무 개발자들은 프레임워크의 내부를 늘 궁금해하는 듯 하다. 어떻게 만들어졌을까. 이런 것을 어떻게 구현했을까. 그러나 프로젝트가 한.. 더보기
NTD 배포 및 어셈블리 로딩 그리고 IIS 설정 어셈블리 로딩과정을 알고 싶다면 바로 아래 링크를 참조한다.2015/10/15 - [04.기술-APP/.NET InDepth] - 어셈블리 바인딩(최종) 현재 참여하고 있는 프로젝트는 ClickOnce와 NTD배포를 혼합해서 사용하고 있다. 다음은 어제밤에 NTD에게서 당한 린치 사건이다. 밤 12시까지 퇴근을 못하고 택시비로 몇 만원을 강탈당했다. 그 사건에 대한 내용을 지금부터 기록해 보려고 한다. 1. 사건 개요 현재 참여하고 있는 기업에서는 처음에 배포 서버에 HTTP핸들러를 하나 제작해서 사용하고 있었다. 그 녀석이 하는 일은 두 가지였다. 하나는, 배포 서버로 퍼블리시(publish) 되는 어셈블리를 디렉토리별로 구분하여 관리할 수 있도록 할 수 있게 하는 역할을 한다. HTTP핸들러는 또한 .. 더보기
어셈블리 바인딩 1 어셈블리 바인딩 관련 최종 버전은 아래 링크로 바로 갈 수 있다.2015/10/15 - [04.기술-APP/.NET InDepth] - 어셈블리 바인딩(최종) 어셈블리 바인딩 1 이번 포스트를 이해한다면 .NET 애플리케이션 특히 NTD 스마트클라이언트 애플리케이션의 많은 부분을 이해할 수 있는 기초가 다져지게 될 것이다. 우리는 다른 어셈블리를 사용하고 싶을때는 VS.NET의 솔루션 탐색기의 프로젝트에서 참조 추가를 통해서 원하는 작업을 쉽게 수행한다. 또는 코드상에서 직접 Assembly.Load(), Assembly.LoadFrom() 메소드를 사용해서 원하는 어셈블리를 메모리로 로딩시키는 경우도 있다. 정적이든 동적이든 대상 어셈블리 파일을 로딩하는 과정은 어셈블리 바인딩(assembly bind.. 더보기
어셈블리 바인딩 2 어셈블리 바인딩 관련 최종 버전은 아래 링크로 바로 갈 수 있다.2015/10/15 - [04.기술-APP/.NET InDepth] - 어셈블리 바인딩(최종) 어셈블리 바인딩 2 퓨전의 바인딩을 알아보기 전에 미리 알아봐야 하는 개념들이 있다. 그것들을 정리한다. 애플리케이션에는 애플리케이션 전체에 대한 설정도 있고 특정 어셈블리에만 적용될 수 있는 환경 설정이 있을 수 있다. 이런 애플리케이션 설정들은 XML형식의 .config 파일로 주어진다. 애플리케이션은 시작하면서 이 설정 파일을 읽어들인다. 퓨전은 어셈블리 바인딩을 수행하면서 설정 정보 중에서 대상 어셈블리에 대한 설정이 있는지를 확인하고, 만약 있다면 그 설정을 대상 어셈블리 검색 과정에 반영하게 된다. 바인딩 과정에서 적용될 수 있는 애플리.. 더보기