0

以下のようなものを使用して、コードで実行時に外部リソースの 1 つをリンクしています。

System.Reflection.Assembly assembly = System.Reflection.Assembly.LoadFrom("MyNice.dll");
            Type type = assembly.GetType("MyType");
            Tool = Activator.CreateInstance(type) as Tool;

ご覧のとおり、オブジェクト作成の最後に、結果のオブジェクトをツール クラスにキャストする必要があります。これは、コード内に Tool クラスのメソッドとプロパティへの参照が多数あるためです。コードはコンパイル時にエラーになります。

参照から Dll を削除し、実行時に動的にロードしたかったのですが、同時に、Tool アセンブリを参照して依存しているコードの一部があるため、これは悪い状況です。どうしたら独立できるでしょうか？コード全体でリフレクションを使用する必要がありますか、それとも簡単な代替手段がありますか?

例えば：

if (Tool.ApplicationIsOpen)
                    return StatusResult.Success;

Tool クラスが既に存在すると想定している同じクラスにあり、参照フォルダーから削除すると壊れます。

何か提案はありますか？

4

1 に答える 1

1

ツールが継承するインターフェイスを含む両方のプロジェクトから参照する共有 DLL を作成することをお勧めします。

この共有プロジェクトで、コンシューマー プロジェクトに必要な機能を公開する ITool などのインターフェイスを作成します。

共有プロジェクト

public interface ITool
{
    void Something();
}

別のプロジェクト

public class Tool : ITool
{
    public void Something()
    {
        // do something
    }
}

消費者プロジェクト

System.Reflection.Assembly assembly = System.Reflection.Assembly.LoadFrom("MyNice.dll");
Type type = assembly.GetTypes().FirstOrDefault(t => t.IsAssignableFrom(typeof(ITool)));
ITool tool = Activator.CreateInstance(type) as ITool;

これで、Tool を含むプロジェクトへの参照を削除できますが、ITool を含む共有プロジェクトへの参照は引き続き必要です。本当に参照が必要ない場合は、リフレクション ルートを調べてください。

この戦略は、多くのプラグイン システムの基礎となっています。この面倒な作業の多くを実行できる Dependency Injection (略して DI) ライブラリを確認することをお勧めします。

DI ライブラリのリストは次のとおりです。 http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx 個人的には、最近 Ninject を使用しています。

関連リンク:

于 2013-08-22T05:11:18.660 に答える