2009-06-15 4 views
2

DI/IOC : 프레임 워크가 너무 많아서 해당 프레임 워크와 관련된 세부 정보가 빠르게 달라집니다. 나는 프레임 워크 (나무를 어둡게하는 숲) 외부에서 그 원리를 배울 수 있다면 나는 종종 새로운 기술을 배우는 것을 발견한다.Dependency Injection/Inversion of Control에 대한 계층화 된 접근법이 있습니까?

내 질문 : DI/IOC의 간단한 원리는 무엇입니까? 나는 무엇이 얻었는지, 옵션은 무엇인지, 비용은 무엇인지, 각각의 간단한 원리에 대해 개략적으로 설명하는 (프레임 워크에 무관심한) 건물 접근법을 찾고있다. 실제로 내 질문에 답변하지 않는 한 링크를 붙여 넣지 마십시오. 그 숲에서 길을 잃고 계속됩니다.}

두 번째 질문 : 핵심 원칙을 이해하면 내 자신의 간단한 프레임 워크를 구축 할 가치가 있습니까? IE의 통찰력은 소비 된 노력에 비례하여 얻게 될 것입니까?

미리 감사드립니다. 로버트

답변

4

내 매우 신속하고 더러운 테이크는

  • 의존성 주입과 반전 컨트롤에없는 같은 일 있습니다. 반전 제어 DI를 사용합니다.

  • IoC는 컴파일 타임이 아닌 런타임에 응용 프로그램을 함께 결합하는 방법입니다.

  • 코드의 형식을 '새로 고치는'대신 런타임에 IoC 컨테이너에 삽입됩니다.

  • a)이 클래스의 생성자를 살펴 봅니다. 모든 매개 변수는 인터페이스입니다. b) 구성 파일을보고 응용 프로그램에서 해당 인터페이스를 나타 내기 위해 선택한 각 인터페이스를 구현하는 클래스를 확인합니다.

    public interface IEmailer 
    { 
        void SendEmail(); 
    } 
    

    그리고 당신은이 인터페이스의 적어도 하나의 구현이 :

여기

이의 당신이 보내는 이메일에 대한 인터페이스 IEmailer 있다고 가정 해 봅시다 아주 기본적인 예제

public class IainsEmailer : IEmailer 
{ 
    public void SendEmail() 
    { 
     // Send email 
    } 
} 

IoC 컨테이너의 단점 그림 파일 (어떻게 든)는 :

IainsEmailer is my choice for IEmailer 

그런 다음 코드에서 다음과 IoC 컨테이너가 IEmailer을 필요가있는 생성자 내로 IainsEmailer를 주입 것을 가질 수 있습니다.

public class MyClass 
{ 
    private IEmailer _emailer; 

    public MyClass(IEmailer emailer) 
    { 
     _emailer = emailer 
    } 

    // You can now use emailer as if you have created it 
    _emailer.SendEmail(); 
} 

나는 계속할 수 있습니다. 그리고. 하지만 이것이 IoC의 전체적인 아이디어입니다.

2

이 다소 일자하지만 좋은 개요 나에게 Inversion of Control

IOC의 드라이브 기본 원칙 부품, 모듈화, 느슨한 결합, 응집력의 개념이다입니다. 즉, 명확한 종속성을 가진 응집력 있고 모듈 식 단위로 나뉘어 진 소프트웨어 또는 다른 장치에 대한 링크를 설계하는 것을 의미합니다. 이것은 프로그래밍뿐만 아니라 모든 분야에서 엔지니어링의 기본 원칙입니다. 모듈성을 갖추면 기능적 시스템을 만들기 위해 이러한 구성 요소를 연결하여 기능적 전체를 구성 할 수있는 방법이 필요합니다. IoC/DI 프레임 워크는 이러한 연결 개념을 추상화하고 구성 요소 간 링크를 선언 한 다음이 링크를 실행할 수있는 코드를 작성할 수있게 해주는 구성 요소입니다. "반전"부분은 구성 요소 자체가 더 이상 종속성에 연결하지 않는다는 사실에서 비롯됩니다. 대신 연결 구성 요소가 외부에서 연결을 수행합니다. 이것은 차례로 의존성 주입 (dependency injection)이라고합니다. 일반적인 IoC/DI 프레임 워크를 사용하면 다른 구성 요소가 의존하는 인터페이스의 특정 구현을 지정하는 코드를 작성한 다음 해당 구성 요소를 인스턴스화 할 수 있으며 생성시 IoC 컨테이너에서 필요한 구현을 제공합니다. 이것은 객체 생성의 개념을 추상화합니다.

1

귀하의 질문에 위키피디아의 모든 기사가 필요합니다. 나는 당신이 이미 실제 기사를 읽었을 것이라고 생각한다. 나의 짧은 질문은 여기에있다 : Dependency Injection은 모두 인스턴스화에 관한 것이다.

주요 개념은 클래스가 종속성을 인스턴스화 할 책임이 있어서는 안된다는 것입니다. DI 프레임 워크는 코드와 (일반적으로) 외부의 구성 메커니즘을 통해 유연하게 수행 할 수 있기 때문에 인스턴스화를 대신합니다. 종속에서

  1. 을 서 분리 :

    이있는 클래스를 작성 할 수 있습니다.

  2. (자신의 의존성보다는) 실제 책임에 더 잘 부합합니다.
  3. 다시 컴파일 할 필요없이 구성을 통해 변경할 수 있습니다.
  4. 더 쉽게 테스트 할 수 있습니다. 대체로 더 잘 설계되었습니다.

는 두 번째 질문에 대답하려면 : 하려는 경우 DI 다음 자신이 분명 과잉이다 프레임 워크를 작성에 대한을 배웁니다. 널리 사용되는 오픈 소스 프레임 워크 중 하나를 선택하고이를 사용하는 코드를 작성하는 것이 좋습니다. 대부분 그 용도로만 좋은 자습서가 있습니다.

다음 레벨로 가져 가면 사용하고 있던 프레임 워크의 소스 코드를 가져 와서 파고들 수 있습니다. 훌륭한 프레임 워크는 잘 쓰여지고 읽기가 비교적 쉽습니다.

행운을 빌어 요! urig

PS - .net에 있다면 MEF로 시작하지 마십시오. Windsor, Unity 또는 Spring.Net에서 시작하십시오. MEF는 DI 프레임 워크보다 더 많고 적습니다. 따라서 잠시 후에 다시 사용하십시오.