DI (Dependency Injection) 관련 프레임워크.

GET/FrameWork
posted by 방랑군 2009. 10. 6. 16:47



DI (Dependency Injection)은 크게 보면 객체간 의존성을 객체에게 맡기는 것이 아니라, 컨테이너가 필요한 시점에 필요한 관련 객체를 만들어 의존성을 해소시켜주는 것이며, 이 과정에서 자연스럽게 생성한 객체들의 라이프 싸이클을 관리하는 기능도 제공하게 된다. 따라서 DI 컨테이너를 사용할 경우에는 이를 사용하지 않을 때에 비해 성능상 약간의 영향을 받게 된다. DI 컨테이너를 사용치 않았을 때는, 다른 객체를 필요로하는 주체가 필요한 객체의 생성자를 직접 호출하여 사용하였기 때문에 직관적이며 이렇게 생성된 코드는 다른 사람이 이해할 때 훨씬 쉬운 면이 있다. DI 컨테이너가 개입되면 객체 생성이 간접적으로 이루어지기 때문에 성능상 약간의 오버헤드도 감안해야 하며, 컨테이너 자체에 대한 교육이나 이해가 필요하게 되어  전반적으로 프로젝트의 복잡도는 약간 증가하게 된다. 따라서, 유행처럼 DI 컨테이너에 대한 관심이 증가하고 있지만, 개발하는 프로그램의 성격상 객체간 의존성이 많지 않고, 의존성이 있다손 치더라도 그다지 복잡하지 않은 경우에는 DI 컨테이너의 사용은 추천할만한 것이 못된다. 객체간 혹은 클래스가 의존성이 많고 복잡하며 이의 해소를 컨테이너에 의지하여 추상화하고자 할때 혹은 런타임시에 이들 객체간 의존성을 변경할 필요가 있을 시에는 Unity와 같은 DI 컨테이너의 적용을 고려해볼 만 하다.

저작자표시

'GET > FrameWork' 카테고리의 다른 글

방랑이가 생각하는 Spring.NET...  (0) 2009.10.06
Spring.NET - 레퍼런스 문서 한글화 사이트..  (0) 2009.09.30
객체의 생명주기  (0) 2009.09.30
Spring 컨테이너와 아키텍처 구성  (0) 2009.09.30
Spring.NET 생명 주기  (0) 2009.09.30

방랑이가 생각하는 Spring.NET...

GET/FrameWork
posted by 방랑군 2009. 10. 6. 15:30


 난 국어가 약하다. 언어로써 받아들이는 능력이 정말 형편없다는 걸 느낀다 ... --;

Spring framework 의 가장 중요한 것은 IoC 컨테이너다.

 먼 뜻일까? 먼가 거대한 숨어있는 기술이 있을거라고 생각하며
수많은 레퍼런스와 사이트를 뒤지며 간단히 설명하는 것을 찾기 위해
삽질하기 수일...
 허망 그 자체 --;

Spring 프레임워크는 AOP 기반 프레임워크라고 한다..
ㅋㅋ AOP...
개념은 "타겟 객체에 대한 호출을 중간에서 인터셉트할 수 있는 방법"이라는 것이다.

나에게 있어서 Spring 는 자유로움 빼았긴 프레임워크이다...

 아주 간단히 설명해서...
프레임워크에 필요한 설정과 바뀔수 있는 값들을 config 항목 즉, Spring  에서 정한
원칙적인 XML 틀에서 움직이는 프레임워크이다..
즉, Config 항목을 XML 의 항목을 다 알고 있어야 쓸수 있다느 것이다..

된장...... 이거 정말 안좋다...

1. 언제 그 항목을 다 마스터 하냐는 것이다....
   다 알아야 머가 필요없는지 뺄꺼 아닌가 ㅋㅋ
2. 기술 구현 프레임워크도 부담스러운데 거기다가 환경파일까지 ...
   부담이 2배다...
3. 사용자 CONFIG 를 하려면 .... 이건 확인 안해봤지만,
   된다면 지겨운 정해진 CONFIG 를 알려고 하기보단
   자기에 맞는 CONFIG 구성해서 기술구현에 끼워맞출려고 할 것이다.
4. 무엇보다 남 만든거 맞추는 거 정말 싫다...

역쉬 안좋다 --;

 이제 그만하련다 Spring ...
IoC 부분은 그만하고 각 필요한 부분의 기술만 좀 보고 말련다..

Spring 별로 매력없다..



   
저작자표시

'GET > FrameWork' 카테고리의 다른 글

DI (Dependency Injection) 관련 프레임워크.  (0) 2009.10.06
Spring.NET - 레퍼런스 문서 한글화 사이트..  (0) 2009.09.30
객체의 생명주기  (0) 2009.09.30
Spring 컨테이너와 아키텍처 구성  (0) 2009.09.30
Spring.NET 생명 주기  (0) 2009.09.30

Spring.NET - 레퍼런스 문서 한글화 사이트..

GET/FrameWork
posted by 방랑군 2009. 9. 30. 16:41


 주소  : http://kune.tistory.com/category/Spring.NET


그 많은 영어를 한글화 하시고 있는 분이다...
맨땅에 헤딩을 안해주시고 있어서 고맙긴 한데......

 핵심 기술만 알고 프로젝트에 적용하고 싶은 FRAMEWORK 은 아니다 .. 솔직히.....


-- 중요 포인트 --

1. Spring framework 의 가장 중요한 것은 IoC 컨테이너다.   
   - 이것만 다룰줄 알면 될 듯....

2. Spring.NET은 all or nothing 솔루션이 아니며, 모듈은 독립적으로 기능을 사용할 수 있다.
   - 필요한 것만... 물론, 핵심인 결정해야하는 단 한가지는, 비즈니스 로직을 Spring의 IoC 컨테이너를 이용하고 웹 레이어를 WebApplicationContext 와 멀티티어 서비스를 제공하느냐 이다.[Spring.Core 인 듯..]

3. 모듈

2.3. 모듈

Spring framework 는 잘구성된 모듈로서 많은 특징을 아래의 그림과 같이 가진다. 아래 그림은Spring.NET의 핵심 모듈을 보여준다.

Spring.Core 는 어플리케이션에서 DI를 사용하도록 설정하는 가장 기초적인 부분을 담당한다. 

Spring.Aop 는 Aspect-Oriented Programming ( 이하 AOP) 의 공통 기능을 수행한다. Spring 의 aspect 라이브러리는 transaction, logging, performance monitoring, caching, method retry, exception handling 에 사용하기 쉽게 정의되어 있다.

Spring.Data 는 data에 access하기 위해 더 효율적이고 일관된 기능을 제공한다. 

Spring.Data.NHibernate 는  ADO.NET 과 NHibernate 수행을 같은 transaction 에서 쉽게 제공하기위해Spring 의 선언적 transaction 관리 모듈이다. NHibernate 1.0 사용자는 data access 동작 수행을 API를 통해 쉽게 사용할 수 있다.

Spring.Web, Spring.Web.Extensions 은 ASP.NET web 어플리케이션 의 추상화 레벨로서databinding, validation, page/control/module/provider 구성의 공통적인 방법을 효율적으로 제공한다.

Spring.Services 는 .NET remoting, Enterprise Service, ASMX web service같은 분산 기술에서 사용하는 .NET 개체를 처리하기 위한 모듈. 이런 서비스는 AOP 의 'decorated' 와 DI을 통해 구성할 수 있다

Spring.Testing.NUnit 은 NUnit 를 통해, 통합 테스트를 위한 모듈 제공

Spring.Core 모듈은 다음과같은 기능을 추가적으로 제공한다.

l  Expression Language - 런타임에 개체의 조작과 효율적인 쿼리 제공

l  Validation Framework - 비즈니스 개체의 복잡한 유효성 확인에 선언적이거나 프로그래밍적 방법을 제공하는 견고한 UI agnostic 프레임워크

l  Data binding GGramework - 데이터 바인딩을 수행하는 견고한 UI agnostic 프레임워크

l  Dynamic Reflection - 높은 성능의 reflection API 제공

l  Threading - Latch, Semaphore, Thread Local Storage 같은 additional 동시성의 추상화를 제공

l  Resource abstraction - file 로 부터의 InputStream 과 다형성과 프로토콜 독립적인 방법의 URL 을 처리하는 공통 인터페이스 제공

    
 


저작자표시

'GET > FrameWork' 카테고리의 다른 글

DI (Dependency Injection) 관련 프레임워크.  (0) 2009.10.06
방랑이가 생각하는 Spring.NET...  (0) 2009.10.06
객체의 생명주기  (0) 2009.09.30
Spring 컨테이너와 아키텍처 구성  (0) 2009.09.30
Spring.NET 생명 주기  (0) 2009.09.30

객체의 생명주기

GET/FrameWork
posted by 방랑군 2009. 9. 30. 15:32

참조 : http://resisa.tistory.com/52

이번 포스트에서는 클래스의 생성자와 소멸자를 통해서 객체의 생명주기에 대해서 알아보고 난 후에 Spring.NET에서 IoC컨테이너에서 객체의 생명주기에 알아보겠습니다.

먼저 변수는 값 타입과 참조 타입이 있으며 값 타입에는 int, double, char 등이며 참조 타입은 class 등입니다. 값 타입은 스택이라는 영역의 메모리에 저장됩니다. 반면에 참조 타입은 new라는 연산자를 통해서 객체가 생성되면 멤버변수들은 힙이라는 영역의 메모리에 저장되며 이 객체 변수는 힙 영역에 메모리를 가리키는 주소값을 가지며 스택에 저장이 됩니다. 그래서 참조 타입이라고 불립니다. 그리고 .NET에서는 가비지 수집기가 존재하여 C++에서 처럼 delete를 해주지 않아도 시점을 알 수는 없지만 가비지 수집기가 힙 영역에 사용하지 않는 메모리를 정리를 해줍니다. 그렇다면 .NET에서는 메모리에 대해서 개발자는 신경쓰지 않아도 될까요? 정답은 상황에 따라서 다릅니다. 우리가 선언하는 변수를 리소스라고 생각할 때 리소스에는 두 가지가 존재합니다. 바로 관리되는 리소스와 네이티브 리소스입니다. 관리되는 리소스는 사용자가 직접 만든 클래스나 .NET Framework에서 제공하는 클래스입니다. 네이티브 리소스는 파일핸들이나 API를 사용하는 리소스입니다. 이 네이티브 리소스는 힙 외부에 할당된 메모리를 사용하기 때문에 가비지 수집기에서 메모리를 해제할 수 없습니다. 네이티브 리소스를 사용하는 프로그램에서는 이 부분에 대한 메모리를 관리해주어야 메모리 누수가 발생하지 않게 됩니다. 그러면 이러한 리소스들을 정리해주는 IDisposable 패턴에 대해서 알아보고 객체의 수명주기에 대해서도 알아보도록 하겠습니다.

public class DisposableClass : IDisposable

{

    private SqlConnection connection;

    private IntPtr fileHandle;

 

    public DisposableClass()

    {

        System.Diagnostics.Debug.WriteLine("생성자입니다.");

    }

 

    ~DisposableClass()

    {

        Dispose(false);

        System.Diagnostics.Debug.WriteLine("소멸자입니다.");

    }

 

    [System.Runtime.InteropServices.DllImport("Kernel32")]

    private extern static Boolean CloseHandle(IntPtr handle);

 

    public void Dispose()

    {

        Dispose(true);

        GC.SuppressFinalize(this);

 

        System.Diagnostics.Debug.WriteLine("Dispose() 호출.");

    }

 

    protected virtual void Dispose(bool disposing)

    {

        if (disposing)

        {

            if (connection != null)

                connection.Dispose();

        }

 

        if (fileHandle != IntPtr.Zero)

        {

            CloseHandle(fileHandle);

            fileHandle = IntPtr.Zero;

        }

    }

 

}

=> DisposableClass 클래스는 관리되는 리소스인 SqlConnection과 네이티브 리소스인 IntPtr를 멤버변수로 가지고 있습니다. 또한 IDisposable 상속받아 구현하고 있는 것을 볼 수 있습니다. 여기서 IDisposable 패턴에 대해서는 자세히 설명하지 않겠지만 Dispose 메소드에서는 Dispose메소드가 호출이 되면 소멸자를 호출할 필요가 없다는 것을 가비지 수집기 에 알려주기 위한 부분(GC.SuppressFinalize(this))이 있으며 매개변수를 가지고 있는 Dispose 메소드가 있어 매개변수가 true일 때는 관리되는 리소스와 네이티브 리소스를 모두 정리하는 것을 알 수 있지만 false일 때(소멸자에서)는 네이티브 리소스만을 정리하는 것을 볼 수 있습니다. IDisposable 패턴에 대한 자세한 사항은 아래의 사이트를 참고 하세요.
http://msdn.microsoft.com/ko-kr/magazine/cc163392.aspx

그러면 이제 DisposableClass 클래스를 생성하도록 해보겠습니다.
 1번 : using 키워드 미사용
DisposableClass disposableClass = new DisposableClass();
 2번 : using 키워드 사용
using (DisposableClass disposableClass = new DisposableClass())

{

       …

}

=> 2번처럼 using키워드를 사용하면 자동으로 Dispose메소드를 호출해주어 리소스를 해제시켜주는 것을 알 수 있습니다. 이렇게 using 키워드를 사용하기 위해서는 당연히 IDisposable
상속받아 구현해주어야 합니다.

여기서 저는 한가지 궁금증이 생겼습니다. SqlConnection과 같이 관리되는 리소스를 using키워드와 함께 객체로 생성하면 변수 connection의 값도 모두 해제되는 것인줄 알았습니다. 하지만 Dispose메소드는 변수 connection의 멤버변수들(리소스)을 해제해주는 것이지 connection의 값(참조주소)이 해제되는 것은 아닙니다. 물론 이 참조값은 int형의 4바이트뿐이 안됩니다. 또한 이 값은 가비지 수집기에 의해서 해제가 됩니다. 가비지 수집기는 어떻게 이 참조값을 해제해주는지 알 수 없지만 가비지 수집기에 명시적으로 이 값을 해제시키는 방법은 있습니다. 바로 connection변수에 null를 넣어주는 것입니다. GC.Collect()란 메소드는 명시적으로 가비지 수집기에게 메모리를 정리하라는 것을 알려줍니다. 만약에 connection변수에 null이란 값을 넣어주고 GC.Collect()를 호출하면 connection변수의 참조값을 바로 해제해줍니다. 실제적으로 코드가 생성되는 것을 한번 살펴보아야 확실히 알 수 있겠지만 제 생각으로는 uisng키워드에서 생성된 객체는 {}에서만 사용할 수 있으며 다른 곳에서는 사용할 수 없는 값이기 때문에 아마 {}안에서 마지막에 null를 대입해주는 것이 아닐까라는 생각이 듭니다.
저작자표시

'GET > FrameWork' 카테고리의 다른 글

방랑이가 생각하는 Spring.NET...  (0) 2009.10.06
Spring.NET - 레퍼런스 문서 한글화 사이트..  (0) 2009.09.30
Spring 컨테이너와 아키텍처 구성  (0) 2009.09.30
Spring.NET 생명 주기  (0) 2009.09.30
Hands-on Labs for EL 4.1 and Unity 1.2  (0) 2009.09.29

Spring 컨테이너와 아키텍처 구성

GET/FrameWork
posted by 방랑군 2009. 9. 30. 15:21

참조 : http://resisa.tistory.com/53

저번 포스트에 이어서 Spring 컨테이너 대해서 아키텍처와 함께 알아보도록 하겠습니다. 먼저 일반적으로 아키텍처를 구성은 프리젠테이션 레이어(PL) -> 비지니스 로직 레이어(BLL) -> 데이터 액세스 레이어(DAL)로 구성되고 모든 레이어에서는 테이블과 매핑되는 도메인 모델을 참조합니다. 이번 포스트에서는 비지니스 로직 레이어에 해당하는 클래스와 데이터 액세스 레이어에 해당하는 클래스를 만들고 두 레이어 간의 관계를 DI기능과 함께 살펴보도록 하겠습니다.

먼저 DAL에 클래스를 먼저 살펴보겠습니다.

public class DAL

{

    public DAL()

    {

        System.Diagnostics.Debug.WriteLine("데이터 생성자 호출");

    }

 

    ~DAL()

    {

        System.Diagnostics.Debug.WriteLine("데이터 소멸자 호출");

    }

 

    public void ExcuteDal1()

    {

        System.Diagnostics.Debug.WriteLine("데이터 Excute1() 호출");

    }

 

    public void ExcuteDal2()

    {

        System.Diagnostics.Debug.WriteLine("데이터 Excute2() 호출");

    }

 

    public void ExcuteDal3()

    {

        System.Diagnostics.Debug.WriteLine("데이터 Excute3() 호출");

    }

}
=> 생성되는 시점과 소멸되는 시점을 알기 위해서 출력창에 스트링을 찍어줍니다. 그리고 3개의 메소드를 가지고 있습니다. 실질적으로 여기서 DB와 커넥션을 하기 위한 패턴이나 프레임워크를 사용하여야 하는데 이번 포스트의 목적은 아키텍처 관점에서 두 레이어 사이의 관계와 레이어에서 생성되는 객체의 생명주기에 대해서 알아보기 위한 것이므로 생략하였습니다.

그럼 이제 BLL클래스를 만들어 보겠습니다. 2가지 방식으로 BLL 클래스를 만들어 보도록 하겠습니다.
1번째로 DAL클래스를 멤버변수로 가지고 있을 경우입니다.

public class BLL

{

    private DAL dal = new DAL();


    //private DAL dal;

 

    //public DAL Dal

    //{

    //  get { return dal; }

    //  set { dal = value; }

    //}


    public BLL()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 생성자 호출");

    }

 

    ~BLL()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 소멸자 호출");

    }

 

    public void ExcuteBll1()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 Excute1() 호출");

 

        dal.ExcuteDal1();

        dal.ExcuteDal2();

    }

 

    public void ExcuteBll2()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 Excute2() 호출");

 

        dal.ExcuteDal2();

        dal.ExcuteDal3();

    }

}

2번째로는 BLL클래스의 메소드 안에 DAL클래스를 사용하는 경우입니다.
public class BLL

{

    public BLL()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 생성자 호출");

    }

 

    ~BLL()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 소멸자 호출");

    }

 

    public void ExcuteBll1()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 Excute1() 호출");

       

        DAL dal = new DAL();

        dal.ExcuteDal1();

        dal.ExcuteDal2();

    }

 

    public void ExcuteBll2()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 Excute2() 호출");

 

        DAL dal = new DAL();

        dal.ExcuteDal2();

        dal.ExcuteDal3();

    }

}
=> 1번과 2번에 차이는 무엇일까요? 1번에서는 BLL 객체를 만들면 DAL 클래스의 생성자가 호출이 되고 BLL 클래스의 생성자가 호출됩니다. 2번에서는 BLL 객체를 만들면 BLL 클래스의 생성자만 호출됩니다.
Spring에서 DI의 기능을 사용하기 위한 일반적인 방법은 생성자(Constructor Injection)나 프로퍼티(Setter Injection)를 이용해서 주입시키는 방법으로 바로 1번에 해당하는 구조입니다. 1번 구조로 DI기능을 이용해서 BLL 객체를 만들어보겠습니다. 1번 구조에서 new키워드를 사용한 부분을 제거하고 주석 부분을 해제한 후에 DI기능으로 DAL 객체를 생성해보겠습니다. 아래는 환경설정 파일과 컨테이너에서 BLL 객체를 가져오는 코드입니다.
<object id="dal" type="ObjectLifeCycle.DAL, ObjectLifeCycle" singleton="false"/>

 

<object id="bll" type="ObjectLifeCycle.BLL, ObjectLifeCycle" singleton="false">

  <property name="Dal" ref="dal" />

</object>
IApplicationContext ctx = ContextRegistry.GetContext();

BLL bll = ctx["bll"] as BLL;

 

bll.ExcuteBll1();

//bll.Dal = null;

//GC.Collect();

bll.ExcuteBll2();
=> 컨테이너에서 BLL 객체를 가져올 때와 1번 구조와의 차이점은 BLL과 DAL 객체의 생성시점입니다.
1번 구조에서는  위에서 말했듯이 DAL 생성자가 호출되고 BLL 생성자가 호출됩니다. 반면에 컨테이너에서 BLL 객체를 가져오면 BLL 생성자가 호출이 되고 DI기능에 의해서 DAL 생성자가 호출됩니다. 어느것이 먼저 생성되느냐에 차이점만 있습니다. 처음에 DI기능을 이용하면 프로퍼티를 호출하는 시점에 DAL 객체를 가져오는 줄 알았습니다. 하지만 BLL 객체를 생성한 이후에 바로 DI기능에 의해서 DAL 객체가 생성이 됩니다. 또한 이 구조에서는 DAL객체를 환경설정 파일에서 prototype으로 생성했지만 BLL 객체가 소멸되기 전까지 DAL 객체는 소멸이 되면 안됩니다. 왜냐하면 이전 포스트에서 가비지 수집기에 객체를 수집할 수 있는 방법으로 null을 대입해주는 방법이 있다고 하였고 위의 예에서 주석 부분을 제거하고 실행하면 예외가 발생하기 때문입니다. bll.ExcuteBll2()이 실행되기 직전에 가비지 수집기에 의해 DAL 객체가 소멸되었기 때문입니다.
그렇다면 바로 2번 구조처럼 BLL 클래스에 종속되지 않으면서 필요한 경우에 DAL 객체를 만들어서 사용하는 방법은 없을까요? 그 방법은 바로 메소드(Method Injection)로 주입해주는 방식입니다. 메소드로 주입해주는 방법은 두 가지 있으며 한 가지는 IObjectFactoryAware를 상속받는 방법과 Lookup Method Injection 방법입니다. IObjectFactoryAware 방법은 Spring 문서에서 권장을 하지 않기 때문에 두 번째 방식으로 구현해보겠습니다.
<object id="dal" type="ObjectLifeCycle.DAL, ObjectLifeCycle" singleton="false"/>

 

<object id="bll" type="ObjectLifeCycle.BLL, ObjectLifeCycle" singleton="false">

  <lookup-method name="Dal" object="dal" />

</object>

public abstract class BLL

{

    protected abstract DAL Dal();

 

    public BLL()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 생성자 호출");

    }

 

    ~BLL()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 소멸자 호출");

    }

 

    public void ExcuteBll1()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 Excute1() 호출");

 

        DAL dal = Dal();

        dal.ExcuteDal1();

        dal.ExcuteDal2();

    }

 

    public void ExcuteBll2()

    {

        System.Diagnostics.Debug.WriteLine("비지니스 Excute2() 호출");

 

        DAL dal = Dal();

        dal.ExcuteDal2();

        dal.ExcuteDal3();

    }

}
=> 환경설정 파일에서는 lookup-method란 키워드와 object라는 프로퍼티(ref가 아닙니다)를 사용하고 있음을 볼 수 있고 BLL 클래스에서는 DAL 객체를 얻기 위한 추상 메소드 Dal()과 추상 메소드를 가지기 위해서 BLL 클래스가 추상 클래스로 변경되었습니다. 그리고 이전처럼 Spring 컨테이너에서 BLL 객체를 생성하고 BLL 객체의 메소드를 실행하면 DAL 객체가 메소드마다 각각 생성되는 것을 확인하실 수 있습니다. 이외에 예제 코드를 이용해서 BLL과 DAL클래스를 singleton과 prototype으로 번갈아 가면서 설정해서 실행해보면 실제로 객체들이 언제 만들어지고 언제 사라지는지를 알 수 있습니다. 또한 Spring에서 제공해주는 AdoTemplate를 singleton으로 생성할 때의 DB커넥션 문제라던지 lookup-method방식에의 추상클래스로 인한 TDD코드 작성시에 혹 나타날 문제점이라던지 추상클래스를 Base클래스로 사용하면서 아키텍처를 구성해보는 방법 등등 여러가지 테스트가 더 필요할 것 같습니다.

2번에 걸쳐 객체의 생명주기에 대해서 알아보았습니다. 객체에 생명주기에 관심이 없으신 분들은 객체 하나 만드는데 너무 복잡한거 아니냐 가비지 수집기가 있는데 왜 그런거에 관심을 가져야 하느냐 반문 하실 수 있습니다. 하지만 진짜 프로그래머라면 어떻게 하면 좀 더 효율적으로 프로그래밍을 할 것인가에 대한 고민은 밥을 먹는것과 같은거 아닐까요?
저작자표시

'GET > FrameWork' 카테고리의 다른 글

방랑이가 생각하는 Spring.NET...  (0) 2009.10.06
Spring.NET - 레퍼런스 문서 한글화 사이트..  (0) 2009.09.30
객체의 생명주기  (0) 2009.09.30
Spring.NET 생명 주기  (0) 2009.09.30
Hands-on Labs for EL 4.1 and Unity 1.2  (0) 2009.09.29

Spring.NET 생명 주기

GET/FrameWork
posted by 방랑군 2009. 9. 30. 15:19


 Spirng.NET의 IoC 컨테이너에서 객체의 생명주기에 대해서 알아보도록 하겠습니다. 먼저 IoC는 이제까지 new라는 연산자를 사용해서 객체를 생성해주던 것을 환경설정 파일에서 객체에 대한 설정을 해주고 프로그램에서 그 객체를 사용하는 것을 의미합니다. 환경설정 파일에서 객체를 생성해 줄 때 윈폼에서는 두 가지 방법이 있습니다. 바로 singleton과 prototype입니다. 아래는 두 가지 방식입니다. 디폴트로 singleton=true입니다.

<object id="car" type="ObjectLifeCycle.Car, ObjectLifeCycle" singleton="true"/>

 

<object id="car" type="ObjectLifeCycle.Car, ObjectLifeCycle" singleton="false"/> 

설정 파일에서 설정한 객체를 사용하기 위해서는 아래와 같이 사용합니다.
IApplicationContext ctx = ContextRegistry.GetContext();

 

Car car = ctx["car"] as Car;

Debug.WriteLine(car.GetHashCode().ToString());
=> IoC컨테이너를 불러와서 그 중에서 아이디가 "car"인 객체를 가져와서 그 객체의 고유한 값인 해쉬코드 값을 출력창에 보여줍니다. 이전에는 무조건 인터페이스 사용해야되는 줄 알았는데 그렇지 않는 것을 알 수 있었습니다. 그리고 여기서 singleton 방식은 해쉬코드값이 당연히 계속 같은 값을 찍을 것이고 prototype방식은 해쉬코드값이 계속 바뀔 것입니다.

다음 포스트에서는 여기에 DI기능을 추가하고 아키텍처에 Spring.NET를 사용할 경우에 객체의 생명주기를 어떤 방식으로 해야 더 효율적인가에 대해서 알아보도록 하겠습니다~
저작자표시

'GET > FrameWork' 카테고리의 다른 글

방랑이가 생각하는 Spring.NET...  (0) 2009.10.06
Spring.NET - 레퍼런스 문서 한글화 사이트..  (0) 2009.09.30
객체의 생명주기  (0) 2009.09.30
Spring 컨테이너와 아키텍처 구성  (0) 2009.09.30
Hands-on Labs for EL 4.1 and Unity 1.2  (0) 2009.09.29

Hands-on Labs for EL 4.1 and Unity 1.2

GET/FrameWork
posted by 방랑군 2009. 9. 29. 13:18


참조 : http://kingcrap.com/entry/Hands-on-Labs-for-EL-41-and-Unity-12



Enterprise Library 4.1 (EL) 과 Unity Application Block 1.2 (Unity) 에 대한 Hands-on Lab이 공개됐다. 국내 닷넷 개발 진영에도 범용 개발 프레임웍에 대한 관심이 고조되고 있고, 점차 많은 적용 사례가 공유되어 신규 개발에 힘을 실어주고 있는 시점에 EL과 Unity에 대한 HOL의 발표는 참으로 적절한 타이밍이라 여겨진다.

Enterprise Library는 이름이 의미하듯이 엔터프라이즈 애플리케이션 개발에 늘 고려하는, 즉 cross-cutting concern이라할 수 있는 기능을 모아 쉽게 적용할 수 있게 만든 라이브러리 모음집이다.

image

현재 EL 4.1에 포함되어 있는 Application block들로는 PIAB (Policy Injection Application Block), Logging, Caching, Cryptography, Data Access, Exception handling, Security, Validation 그리고 Unity가 있다. EL 4.1 HOL은 바로 이들 각각에 대한 HOL을 C#과 VB로 제공하여 쉽게 따라하며 익힐 수 있게 구성되어 있다.

image

좌측 그림 가운데 Interception (w/ PIAB and Unity), Unity, Validation은 새롭게 추가된 것들이며, 그외 나머지 HOL은 이전 버전의 것을 업데이트한 것이다.

EL과 Unity가 호스팅되고 있는 Codeplex를 방문하면 좀 더 상세한 정보를 알아 볼수 있다.
EL 4.1 ": http://www.codeplex.com/entlib
Unity : http://www.codeplex.com/unity

각각의 HOL의 다운로드 위치는 다음과 같다.
EL 4.1 HOL
Unity 1.2 HOL

MSDN에서도 EL과 Unity에 대한 상세한 정보를 찾을 수 있다.
EL 4.1
Unity 1.2

참고로 EL과 Unity를 포함하여 p&p에서 제공하는 각종 asset들을 활용하여 개발자 생산성이 40%까지 향상될 수 있다는 조사 보고서도 여기서 살펴볼 수 있다.

 

p&p 팀에서는 또한 Enterprise Library 다음 버전에 담고 싶은 기능에 대한 온라인 설문 조사를 진행하고 있다. 평소에 담고 싶었던 내용이 있었다면 한번쯤 의견을 전달하는 것도 좋을 것으로 생각된다.

EntLib_voting_2



저작자표시

'GET > FrameWork' 카테고리의 다른 글

방랑이가 생각하는 Spring.NET...  (0) 2009.10.06
Spring.NET - 레퍼런스 문서 한글화 사이트..  (0) 2009.09.30
객체의 생명주기  (0) 2009.09.30
Spring 컨테이너와 아키텍처 구성  (0) 2009.09.30
Spring.NET 생명 주기  (0) 2009.09.30

티스토리툴바