의존성 주입은 어떻게 언어에 통합 될 수 있습니까? [닫은]

10

의존성 주입이 C #과 같은 언어에 직접 더 잘 통합 될 수있는 방법에 대해 조금 생각하고 있습니다. 나는 당신의 의견을 듣고 싶은 잠재적 인 해결책을 생각해 냈습니다. 많은 의존성 주입 프레임 워크를 사용하지 않아서 간과하는 것이있을 수 있습니다.

어쨌든 아이디어는 키워드를 사용하여 속성을 "주입 가능"으로 선언 할 수 있도록하는 것입니다. 객체가 인스턴스화되고 해당 속성이 생성자 또는 객체 이니셜 라이저를 통해 초기화되지 않으면 전역 서비스에서 해당 속성 유형의 인스턴스를 요청합니다.

마찬가지로 주입 된 속성 유형을 인스턴스화 할 수 있도록 다른 유형의 핸들러를 해당 서비스에 등록합니다.

이러한 종류의 아키텍처 IMO를 사용하는 것의 장점은 상당히 유연하고 사용하기 쉽다는 것입니다. 단점은 주입이있는 클래스를 시작할 때마다 싱글 톤에 콜 아웃을 수행하는 데 약간의 오버 헤드가있을 수 있다는 것입니다.

그런 다음 고성능 솔루션에서 자주 인스턴스화되는 클래스의 경우에만 문제가되므로 큰 문제가되지 않습니다. 아마도 그러한 경우에 일종의 팩토리를 사용할 수 있습니다.

생각, 문제, 질문, 더 나은 아이디어?

암호

public class SomeClass
{

  public SomeClass()
  {
     //implicit behavior if Animal is not set in constructor or initializer
    this.Animal =  GlobalInjector.Get(this,typeof(Mammal))

  }

  public injectable Mammal Animal  
  {
   get;
   set;
  }
}


 GlobalInjector.Register(typeof(Mammal), () => return new Mammal(someParameter));

programming-languages dependency-injection ioc-containers

— 홈데
소스

DI에 익숙하지 않은 사람들을 위해 의사 코드 예제를 제공 할 수 있습니까? 추신. 어쩌면 DI에 관한 내 질문에 대답 할 수 있습니까? :)

— Steven

2

확실하지 않습니다. 글로벌 DI 컨테이너와 키워드 대신 '[Injectable]'속성으로 모든 것을 얻을 수 있습니다.

— Nikie

안녕하세요, 저는 귀하의 질문에 DI에 대해 조금 작성하려고했지만 확실하지 않습니다

— Homde

nikie : 네, 물론 다른 방법으로 실제 메커니즘을 구현할 수있을 것 같습니다. 기본 논리가

— 적절

그렇다면 추가 키워드 이외의 기존 IoC와 다른 점은 무엇입니까?

— Matthew Whited

7

언어에 속하는 것들과 그렇지 않은 것들이 있습니다. 오래 전에 C는 IO가 컴퓨팅 모델 외부에 있고 함수 라이브러리로 구현 될 수 있기 때문에 언어에 속하지 않았다는 것을 인식했습니다.

의존성 주입은 이와 같습니다. 언어 외부에 있으며 적절한 프레임 워크로 구현할 수 있습니다.

현대 언어의 문제점 중 하나는 너무 많은 것을 시도한다는 것입니다. 결국 프로그래머가 간단한 언어로 도망 치면서 이러한 언어는 자체 무게로 무너집니다.

— 밥 삼촌.
소스

나는 이론에 동의하지만, 모든 기능이 부풀어 오르지 않고 언어의 특징 인 언어를 가질 수는 없습니다. 그러나 더 나은 코드를 작성하는 데 도움이되는 새로운 추상화를위한 여지가 항상 있습니다. 아마도 의존성 주입 그 자체는 해결해야 할 문제가 아니라 해결해야 할 문제, 즉 의존성을 줄이는 것이 더 쉬운 방법 일 것입니다. 이것은 최선의 방법은 아니지만 :)

— Homde

5

필요하지 않습니다

내가 사용한 최고의 DI 프레임 워크에 대해 내가 가장 좋아하는 것 중 하나는 최상위 구성 코드가 코드에 대해 DI에 대해 알아야하는 유일한 부분이라는 것입니다. 자동 배선은 컨테이너 및 구성 / "모듈 로딩"수준에서 수행되며 응용 프로그램 코드는 완전히 알 수 없습니다.

이것은 속성, 마술 문자열, 규칙이 없음을 의미합니다. 각 코드는 생성자 (/ properties / methods)에서 코드를 수락한다는 것만 알고 있습니다.

이와 같은 디자인을 사용하면 Dependency Injection을 지원하기 위해 언어를 전혀 변경할 필요가 없습니다.

잠재적으로 위험합니다

언어 통합 의존성 주입 시스템에 대해 내가 가장 두려워하는 것은 다른 구현에 대한 장벽을 제기 할 것이지만 아마도 어떤면에서 모퉁이에 페인트 칠할 것입니다.

구석에 자신을 칠할 수있는 몇 가지 방법 :

XML 기반 구성 만 지원하거나 코드 기반 구성 만 지원
팩토리 디자인 패턴을 완벽하게 지원할 수 없음 (일시적 구성 요소가 아닌 런타임 생성 구성 요소)
어떻게 든 코드를 변경하여 종속성 주입을 사용해야했고 단위 테스트를 위해 클래스를 인스턴스화 할 수 없었습니다.
사용자 정의 수명주기를 지원하지 않음
확장 불가능
더 큰 사용자 정의가 필요한 경우 교체 할 수 없습니다
.Net 사용자는 함정을 알기 위해 오랫동안 DI를 사용하지 않았기 때문에 아직 이해하지 못하는 방식으로 망가졌습니다.

— 멀린 모건 그레이엄
소스

4

.NET 4와 함께 제공 되는 Managed Extensibility Framework 를 보셨습니까 ? 다음 은 몇 가지 예제로 작성한 기사 입니다. 기본적으로 런타임 검색 기능이 추가 된 .NET에 내장 된 종속성 주입 형식입니다.

속성 주입은 다음과 같습니다.

class Program
{
    [Import]
    public IMessageSender MessageSender { get; set; }
}

생성자 주입은 다음과 같습니다.

class Program
{
    [ImportingConstructor]
    public Program(IMessageSender messageSender) 
    {
    ...
    }
}

메타 데이터를 사용하여 지연 가져 오기를 포함하여 필드 가져 오기, 선택적으로 가져 오기, 서비스 콜렉션 가져 오기를 통해 인스턴스화 할 적절한 서비스를 검색 할 수 있습니다. 런타임시 다시 가져 오기하여 새로운 확장을 찾을 수도 있습니다.

— 스콧 위 틀락
소스

MEF는 정말 플러그인 물건 냉각되는 동안 나는 일반적인 DI 메커니즘으로 사용하려는 생각하지 않는다

— Homde

1

@MKO-누락 된 부분을 자세히 설명 할 수 있습니까? 글렌 블록 (Glenn Block)이 MEF 가 모든 DI 프레임 워크를 대체 하지는 않는다고 사람들을 안심시키기 위해 경쟁하는 모든 기사를 알고 있습니다. 그러나 MEF가 다른 DI 프레임 워크에 비해 부족한 기능 목록을 제공 할 수 있다면 사람들이 정보에 입각 한 결정을 내리는 데 도움이됩니다. 또한 C #의 DI 프레임 워크에 대한 질문이 있으며 MEF는 .NET 프레임 워크의 DI 컨테이너입니다.

— Scott Whitlock

2

IMHO가 까다로운 구성 메커니즘을 실제로 설명하지는 않습니다. 한 스레드에서 실행되는 모든 코드가 DB 연결 A를 사용하고 다른 스레드 연결 B의 모든 코드를 어떻게 사용하게합니까? 현재 로그인 한 사용자가 액세스 할 수 없으므로 특정 리소스의 주입을 어떻게 차단합니까?
글로벌 인젝터를 사용하지 마십시오. 전역적인 것을 전혀 사용하지 마십시오. 그렇지 않으면 전역 변수를 사용할 수도 있습니다. 글로벌 대신 싱글 톤 또는 "정적"과 같은 OOP- 스피크를 사용한다고해서 글로벌 특성이 바뀌지는 않습니다.
동적으로 범위가 지정된 컨테이너를 고려하십시오. 어휘 범위 지정은 동적 범위 지정에 대해 정당한 승리를 거두었지만 동적 범위는 전역 범위를 대체 할 수 있다고 생각합니다. 차등 상속은 프로토 타입 기반 상속과 같은 훌륭한 구현입니다.
나는 언어로 정의 된 DI 메커니즘이 정말로 단순해야한다고 믿습니다. C #과 Java의 표준 인 기업적인 것은 없습니다. 간단한 구성 계층이 위에있는 동적 범위 지정 메커니즘이 트릭을 수행 할 수 있습니다. 엔터프라이즈 솔루션은 타사에 의해 계층화 될 수 있습니다.

— 와쿼
소스