次のパターンを簡単に使用できるのに、なぜ依存性注入フレームワークを使用するのでしょうか?
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) 高速 (コンテナ内でルックアップが不要)
3) よりシンプルに
これは私がそれを使用する方法です:
unit uBusiness;
interface
[...]
implementation
uses
uSomeServiceIntf;
[...]
procedure TMyBusinessClass.DoSomething;
var
someService: ISomeService;
begin
someService := CreateSomeService;
someService.SomeMethod;
end;
end.
このアプローチの代わりに DI フレームワークを使用する理由は何ですか?
DI フレームワークを使用すると、これはどのように見えるでしょうか?
私が知る限り、具体的なクラスをインターフェイスに対して登録するよりも DI フレームワークを使用する場合は、システムのコンシューマーが特定のフレームワークの実装を要求します。したがって、登録呼び出しがあります。
DIFramework.Register(ISomeInterface, TSomeInterface)
ISomeInterface の実装が必要な場合は、DI フレームワークに要求できます。
var
someInterface: ISomeInterface;
begin
someInteface := DIFrameWork.Get(ISomeInterface) as ISomeInterface;
明らかに、パラメータを渡して ISomeInterface を作成する必要がある場合は、DIFramework を使用すると全体がより複雑になります (ただし、上記のアプローチでは単純です)。