3

DI には Microsoft の Unity を使用しています。動的なアスペクト ウィービングには、Rapier-LOOM を使用しています。

アスペクト ウィーバーでは、ファクトリ メソッドを使用して織り込まれたオブジェクトをインスタンス化する必要がありWeaver.CreateInstance(System.Type)、既存のインスタンスを織り交ぜる手段は提供されません。

DI コンテナーを使用IUnityContainer.Resolve(System.Type)すると、依存関係を解決し、注入された型のオブジェクトをインスタンス化するメソッドを使用して、依存関係を解決できます。

これら 2 つのアプローチは明らかに矛盾しています。 この競合を解決するための推奨される方法は何ですか?

私がこれまでに持っていたアイデア：

  • マッピングを照会し、依存関係を「手動で解決」します (IUnityContainer.Registrationsプロパティを使用)。結合された「DI + AOP」メカニズムを作成します。これは、解決するタイプを指定して、ターゲットのマップされたタイプを見つけ、Weaver を使用してインスタンス化します。
  • IUnityContainer(Activator の代わりに) Weaver を使用してインスタンス化するインターフェイスの独自の実装を作成します。

PS

私がここで軌道に乗っておらず、競合を解決するのではなく回避できる場合は、お知らせください。

4

3 に答える 3

2

LOOM コードプレックスのページを一目見ただけでは、Unity メソッド インターセプトを使用して実行できない機能は提供されていないようです。ここから読み始めてください:アスペクト指向プログラミング、傍受、Unity 2.0

于 2011-11-10T15:53:26.007 に答える
2

私は Rapier-LOOM に詳しくないので、Unity 側から話します。さまざまな機能/複雑さのいくつかのアプローチがあります。幸いなことに、IUnityContainer を再実装する必要はありません。

あなたができる最も簡単なことは、InjectionFactory を使用してウィーバー経由で作成したい型を登録することです。これにより、デフォルトの動作の代わりにインスタンスを作成するために実行されるデリゲートを指定できます。このようなもの：

  container.RegisterType<ISomething>(
    new InjectionFactory(c => {
        var newObject = (Something)Weaver.CreateInstance(typeof(Something));
        newObject.Property1 = c.Resolve<TypeOfProperty1>();
        newObject.Property2 = c.Resolve<TypeofProperty2>();
        return newObject;
    });

次に、container.Resolve() を呼び出すと、そのデリゲートが実行されます。

2 つ目の方法は、Weaver.CreateInstance 呼び出しを作成チェーンにフックする Unity 拡張機能を作成することです。メイン戦略チェーンでカスタム戦略を使用するか、ビルド計画をオーバーライドしてみてください。前者ははるかに簡単です。

Unity 拡張機能を作成するためのリファレンスが手元にないため、今はこのテキスト ボックスにコードを入力しようとはしません。Unity 拡張機能の例を Web で探してください。物事がどのように連携するかを理解すれば、それらは非常に簡単です。

于 2011-11-12T01:10:52.787 に答える
1

これは不十分な議論です。Microsoft の Unity は、.NET フレームワークでは実現できない機能を提供していないと言っても同じです。問題は、私の問題に最適なプログラミング モデルは何かということです。答えは、要件を実装するために必要なコードの量である可能性があります。AOP、特に Rapier-LOOM.NET は単純なメソッド開始機能ではありません。AOP の目標は、分野横断的な懸念をカプセル化することです。そのためには、アドバイス、紹介、ジョインポイント変数、コードベースの注釈などが必要です。単純なトレースの例以上のものを実装したい場合は、メソッドの開始よりも強力な概念が必要です。

于 2012-03-11T09:29:03.733 に答える