11

다음 패턴을 간단하게 사용할 수있을 때 왜 Dependency Injection Framework를 사용합니까?Delphi Dependency Injection : Framework 대 Delegating Constructor

unit uSomeServiceIntf; 

interface 

type 
    ISomeService = interface 
    procedure SomeMethod; 
    end; 

var 
    CreateSomeService: function: ISomeService; 

implementation 

end. 

unit uSomeServiceImpl; 

interface 

type 
    TSomeService = class(TInterfacedObject, ISomeService) 
    procedure DoSomething; 
    end; 

function CreateSomeService: ISomeService; 

implementation 

function CreateSomeService: ISomeService; 
begin 
    Result := TSomeService.Create; 
end; 

procedure TSomeService.DoSomeThing; 
begin 
    ... 
end; 

end. 

unit uInitializeSystem; 

interface 

procedure Initialze; 

implementation 

uses 
    uSomeServiceIntf, 
    uSomeServiceImpl; 

procedure Initialze; 
begin 
    uSomeServiceIntf.CreateSomeService := uSomeServiceImpl.CreateSomeService; 
end; 

end. 

나는 프레임 워크를 사용하는 대신이 일을하지만 지금까지 나는 단지이 간단한 접근 방법의 이점 볼의 장점 파악하는 것을 시도하고있다 :

1) 매개 변수화 된 생성자는 구현하기가 쉽습니다. 예 : var CreateSomeOtherService : function (aValue : string);

2) 용기에 필요한 빠른 (NO 조회)

3) 더 간단

이 내가 그것을 사용하는 것이 어떻게하십시오 DI를 사용하도록 추론이 될 것입니다 무엇

unit uBusiness; 
interface 
[...] 
implementation 

uses 
    uSomeServiceIntf; 
[...] 
procedure TMyBusinessClass.DoSomething; 
var 
    someService: ISomeService; 
begin 
    someService := CreateSomeService; 
    someService.SomeMethod; 
end; 

end. 

이 접근 방식 대신 프레임 워크?

DI 프레임 워크를 어떻게 사용합니까?

DI 프레임 워크를 사용하는 것보다 인터페이스에 대해 구체적인 클래스를 등록하면 시스템의 소비자가 주어진 프레임 워크를 구현하도록 요청할 것입니다. 는 그래서 등록 호출이있을 것입니다 :

DIFramework.Register(ISomeInterface, TSomeInterface) 

당신이 ISomeInterface 구현을 필요로 할 때 당신은 그것을위한 DI 프레임 워크를 요청할 수 있습니다 : 당신이 만드는 매개 변수를 전달해야합니까 분명히 경우 지금

var 
    someInterface: ISomeInterface; 
begin 
    someInteface := DIFrameWork.Get(ISomeInterface) as ISomeInterface; 

을 ISomeInterface는 DIFramework로 복잡해진다. (위에서 설명한 접근 방식으로는 간단하다.)

+0

DI 컨테이너를 사용하여 소스 코드 예제를 추가하여 선언과 사용의 차이를 명확하게 할 수 있습니까? – mjn

+0

"편의"란 무엇을 의미하는지 확실하지 않은가요?. 영향? –

+0

@Warren, 아마도 OP는 패턴이 exeplified 또는 DI 컨테이너를 선택하는 이유를 알고 싶어 ... –

답변

6

귀하의 경우에는 미리 디자인 타임에 공장 기능 ptr (var CreateSomeService)의 이름을 알아야합니다. 물론 인터페이스와 함수 ptr은 동일한 델파이 유닛 파일에 함께 결합되어 있지만 델파이 유물 일뿐입니다. 글로벌 var은 스레드로부터 안전하지 않으며 액세스 보호되지 않습니다.

그리고 일부 기능이나 설정 파일에서 읽은 결과로 런타임에 인터페이스를 얻은 경우 구현 자의 실제 인스턴스를 얻기 위해 어떤 팩토리 함수를 호출해야하는지 알 수 없습니다.

DIFrameWork.Get(ISomeInterface) as ISomeInterface은 공장 기능을 숨 깁니다. 따라서 인터페이스는 팩토리 기능이 아니라 인터페이스 만 필요합니다. 팩토리 함수를 숨기려면 매개 변수를 숨겨야합니다. (그리고 DI 프레임 워크와 비슷한 것으로 끝날 것입니다).

관련 문제