2009-06-04 4 views
2

私はCOMオブジェクトの上にAPIを書いています。COMオブジェクトのほとんどすべての型と静的メソッドに渡す必要があります。私のAPI。IoCコンテナを使用するオーバーロードメソッドを持つ

私の質問は、COMオブジェクトを受け取り、代わりにIoCを解決したオーバーロードされたメソッドを代わりに持っているので、APIのユーザーは渡すことを心配する必要はありませんまたはCOMオブジェクト内のオーバーロードされたメソッドを削除して、それを渡すオプションを使用して解決する必要があります。

ここでは説明しにくいビットです。

コンストラクタの例;

FooType(IComObject obj,string table) {} 
FooType(string table) : this(Ioc.Resolve<IComObject>(), table) {} 

又は単に

FooType(string table) : this(Ioc.Resolve<IComObject>(), table) {} 

静的メソッドの例;

public static SomeType Create(IComObject obj,string table) 
{ // Do some work with obj} 

public static SomeType Create(string table) 
{ 
    return MyClass.Create(Ioc.Resolve<IComObject>(),table); 
} 

やオーバーロードを持つだけ

public static SomeType Create(string table) 
{ 
    IComObject obj = Ioc.Resolve<IComObject>(); 
    return MyClass.Create(Ioc.Resolve<IComObject>(),table); 
} 

私の最大の心配はそれだけで偏屈呼び出すメソッドの多くを作成するために起こっているということです。ここには他にどのような選択肢がありますか、それともこれが正しい方法ですか?

P.S実際に、IComObjectのインスタンスをすべてアプリケーションに渡す必要はありません。

+1

これは次の質問の続きです:http://stackoverflow.com/questions/947378/ioc-vs-global-variable-in-library to me? – jerryjvl

+0

ええ、それは一種のもので、この中の汚点と発見可能性についてもっと心配しています。 –

+0

と私がやっていることをするのが正しければ。 –

答えて

4

依存性注入の原則の1つは、クラスの依存関係を外部に明示する必要があるということです。あるクラスが依存関係自体を解決すると(その2番目の例のように)、それはその原則に反するものであり、シングルトンサービスを使用する道に戻っています。しかし、IoCコンテナを "エスケープサービス客体を嘲笑するための "ハッチ"。

明らかに、すべてのオブジェクトのコンストラクタにすべてのパラメータがロードされているのは面倒ですが、それはIoCコンテナが入る場所です。自動配線をサポートしていて、設計通りに使用している場合は最初はほとんどのインスタンスを解決する必要があります。つまり、最初のオブジェクトを取り出すだけで、すべての依存関係が準備された状態になり、すべての依存関係が設定された状態になります。このため、Joshua Flanagan makes the argument IoCコンテナは本当にIoC Composersと呼ばれるべきです。

APIのユーザーに負担をかけたくない場合は、IoCコンテナをラップアップし、設定されたインスタンスを呼び出しコードで消費するために、そのオブジェクトをプルする方法について教えてください。

2

私は、 のオーバーロードを許さなければならない魅力的な理由がない限り、オーバーロードと解像度の両方を持つことで、APIが不必要に複雑になり、ユーザーの邪魔になる可能性があります。

あなたは「P.S私は本当にユーザーに負担をかけたくありません」と言ったときにあなた自身の質問に答えたと思います。

1

片側からあなたがテスト中IComObjectタイプのモックオブジェクトを登録し、簡単にこれらのテストを実行することができますので、あなたは簡単にすべての

public static SomeType Create(IComObject obj,string table) 

のようなメソッドをドロップすることができます。
しかし、これはSoCとOpen/Closedの原則を破ります。この場合、あなたのメソッドはあまりにも多くのことを知っています(DIなどがあります)。デザイン(アーキテクチャ)側からは、 "Create(IComObject obj、string table)"のようなメソッドを使用し、Ioc.Resolve()の使用を縮小し、イニシャライザ、ファブリックまたはこのようなものでのみ使用するコードをリファクタリングする方が良いです。すべてのコードを見ることなくこれをリファクタリングする方法を説明するのは非常に難しいです。
答えは - それは依存しています。
編集:
この場合、very good postがあります。それをチェックする、答えが含まれています=)

+0

投稿へのリンク+1 –

1

ユーザーがIComObjectインスタンスを気にしている場合は、過負荷を作成する方法があります。

IComObjectがユーザの実装の詳細であり、テストを気にする唯一の人であれば、クラスが内部でIComObjectのインスタンス化/アクセスに使用する単純なファクトリメソッドを公開する必要があります。

一般に、ユーザがIComObjectを気にすると、過負荷を作成しても負担はかかりません。個人的に開発者として私は常にが私が得ることができる多くのオプションが欲しい。

関連する問題