4

今後のプロジェクトでは、依存性注入とアスペクト指向プログラミングの両方を使用する予定です。DIY依存性注入ガイドに従って、前者を自分で実装し、AOP部分にLOOM.Netを使用します。

ロジック クラスとアスペクト クラスの織り交ぜた型を作成する一般的なパターンは次のとおりです。

AspectClass aspect = new AspectClass();
LogicClass logic = Weaver.Create<LogicClass>(aspect);

私の直感は、グルーコードで織り交ぜを実行することです。たとえば、によって実装されるクラスConcreteLogicAに依存ILogicAします。ILogicBConcreteLogicB

class MyInjector
{
    ...
    public ILogicA GetLogicA(AspectClass aspectToInterweave)
    {
        return Weaver.Create<ConcreteLogicA>(aspectToInterweave, GetLogicB(aspectToInterweave));
    }

    public ILogicB GetLogicB(AspectClass aspectToInterweave)
    {
        return Weaver.Create<ConcreteLogicB>(aspectToInterweave);
    }
    ...
}

これは実行可能な解決策でしょうか、それとも軌道から外れていますか。利点は、自分のロジックと自分のアスペクトを混在させる必要がないことです (これは確かに AOP の手がかりのようなものです) が、このようにして、グルー コードにもう少しロジックを追加しています。

4

2 に答える 2

4

あなたは新しいプロジェクトを始めているので、 SOLIDソフトウェアの設計原則を詳しく調べて、新しいプロジェクトに適用することをお勧めします。適切な抽象化を使用し、SOLID 原則に準拠してアプリケーションを設計した場合、LOOM や PostSharp などのコード ウィービング ツールを使用する理由はほとんどありません。これらのツールは、簡単に変更できないレガシー コード ベースを既に持っているという不運な立場にある場合に特に価値があります。

コード ウィービングを使用する代わりに、アプリケーションの設計に導かれます。適切な抽象化を使用してアプリケーションを設計すると、デコレーターを使用して分野横断的な懸念事項を簡単に追加できます。適切な抽象化を使用して設計されたシステムの例は、こことここにあります。

これらの記事では、デコレーターを使用して分野横断的な関心事を定義する方法について説明しています。このようにシステムを設計すると、分野横断的な問題の実装を残りのコードとは別にテストできます。コード ウィービング ツールを使用する場合、これははるかに困難です。適切な抽象化を使用すると、これは簡単になります。

ここ数年、私はいくつかの企業に相談し、柔軟性と保守性を向上させるために設計パターンを正しく適用する方法を開発者に教えてきました。彼らのレガシー コード ベースの実現は非常に困難でしたが、あなたは新しいプロジェクトを開始するという幸運な立場にいるようです。

これを機会として使用して、設計スキルを向上させ、アプリケーションを今後何年も維持できるようにしてください。

于 2014-10-09T10:13:51.187 に答える
0

動的インターセプトをサポートする依存性注入コンテナーを使用することで、問題を解決できると思います (ほとんどの場合)。このリポジトリは、既存のコードをアスペクトに向けてリファクタリングするプロセスを示しています。Castle Windsor DI コンテナを使用しています。IL ウィービングの代わりに動的インターセプトを使用してアスペクトを実装する利点は、依存関係をアスペクトに簡単に挿入でき、アンビエント コンテキスト/サービス ロケーターに依存する必要がないことです。

于 2015-09-10T11:12:12.457 に答える