본문 바로가기

전체 글

개발 프레임워크 만들기 대장정 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 파일로 주어진다. 애플리케이션은 시작하면서 이 설정 파일을 읽어들인다. 퓨전은 어셈블리 바인딩을 수행하면서 설정 정보 중에서 대상 어셈블리에 대한 설정이 있는지를 확인하고, 만약 있다면 그 설정을 대상 어셈블리 검색 과정에 반영하게 된다. 바인딩 과정에서 적용될 수 있는 애플리.. 더보기
어셈블리 구조 어셈블리(Assembly) 구조 이제 어셈블리(Assembly)라는 것을 구체적으로 알아볼텐데, 어셈블리에 대한 이해가 스마트클라이언트 애플리케이션의 어떤 문맥에서 필요한지 그 상황을 먼저 정리해 본다. 어셈블리와 바인딩 그리고 NTD 배포 어셈블리의 바인딩과 로딩은 스마트클라이언트 애플리케이션에서는 중요한 주제중의 하나이다. 어셈블리에 대한 이해가 필요한 곳이 바로 이 바인딩/로딩과 관련이 있다. 애플리케이션이 어셈블리를 호출( 즉 어셈블리에 포함된 타입을 사용)하게 되면 해당 어셈블리가 아무 고민없이 바로 로딩되는 것은 아니다. 애플리케이션이 참조하고 있는 어셈블리에 대한 정보는 우선 .NET 프레임워크의 CLR에 전달된다. 그 CLR은 이 어셈블리를 어느 위치에서 찾아야 하는가를 고민해서 결정해야 .. 더보기
GAC은 어떻게 생겼을까 GAC(Global Assembly Cache) GAC(Global Assembly Cache)은 머신 차원의 공용 저장소로 이곳에 등록된 어셈블리는 머신에 설치된 모든 애플리케이션에서 같이 사용할 수 있다. 여러 애플리케이션에서 어셈블리에 접근하려면 그 어셈블리는 CLR이 인식할 수 있는 디렉토리에 있어야 한다. 참조하는 어셈블리를 애플리케이션이 로딩하려고 하면 CLR은 자동적으로 미리 정해진 그 디렉토리 구조를 따라가며 검색할 것이다. GAC은 CLR이 이해할 수 있는 디렉토리 구조를 갖는다. GAC은 그러나 단순한 디렉토리가 아니다. 어셈블리의 버전닝 정책 즉 파일명은 같지만 버전번호가 다른 어셈블리가 동시에 존재할 수 있는 디렉토리 구조이며, 그리고 우연히 두 회사에서 출시한 어셈블리의 파일명이 .. 더보기
애플리케이션 도메인과 속성들(베이스 디렉토리) 애플리케이션 도메인(AppDomain)과 환경 속성들 이 포스트에서는 애플리케이션 도메인과 그와 관련된 도메인 속성들에 대해서 알아본다. 이 포스트에서 중요한 개념은 애플리케이션의 베이스 디렉토리와 환경 설정 파일 .config이다. 애플리케이션의 베이스 디렉토리의 개념을 이해하는 것은 특히 스마트클라이언트 애플리케이션에서의 어셈블리 바인딩과 배포(특히 NTD배포)를 이해하는데 있어서 중요한 개념이다. 애플리케이션 도메인은 AppDomain이라는 클래스로 구현되어 있다. AppDomain에는 여러가지 환경 정보들을 가지고 있고, 이런 정보들은 퓨전을 제어하는 중요한 정보들이다. AppDomain의 환경 속성값들은 퓨전이 어셈블리를 검색할 때 이용하게 되는 중요한 정보들이다. 이런 환경 속성값들은 애플리케.. 더보기
강력한 / 약한 이름의 어셈블리(일치 비교, 배포, 보안체크) 1. 어셈블리의 일치 비교(assembly identity comparison) 어셈블리의 일치 비교는 어셈블리가 바인딩이 되고 로딩이 일어나려 할때 수행되고, 또한 어셈블리가 로딩되면, 로딩된 어셈블리의 캐시( LoadContext, LoadFromContext)에 캐싱이 되는데 새로운 어셈블리를 로딩하려고 할때 이 어셈블리가 이미 로딩되어 캐시에 있는지를 확인할때도 어셈블리 일치에 대한 비교 작업이 수행된다. 이런 어셈블리 일치에 대한 판정은 강력한 이름의 어셈블리과 약한 이름의 어셈블리가 다른 비교 로직을 거치게 된다. 강력한 이름의 어셈블리와 약한 이름의 어셈블리는 내부 구조에 있어서는 동일하다. 구조적인 면에서의 차이점은 강력한 이름의 어셈블리는 디지털 사인을 추가했다는 것이다. 디지털 사인이 .. 더보기

티스토리툴바