0

先週、友人と DLL (.net DLL) 内のクラスの使用について話し合いました。Exeでそれを消費する必要がある.net DLLがあります。

通常は、

  1. ソリューションに DLL を追加し、Exe で DLL を参照します。
  2. クラスのオブジェクトを作成します（これは私のDLLにあります）
  3. 作成したばかりのオブジェクトから、クラス内のメソッド /function の呼び出しを開始します。

しかし、最終的には、私たちが行っている方法ではなく、リフレクションを使用する必要があると判断しました。理由は疎結合です。DLL の機能を変更してコンパイルすることができます。このような状況では、クライアント コードをコンパイルする必要はありません。

この背景について質問があります。

非常に単純なアプリケーション (たとえば、コンソール アプリケーション) があり、2 つのクラスがあり、どちらも異なる作業を行うように記述されているとします。

class Program
{
    static void Main()
    {

        //How do you create a object of the class A. 

    }
}


class A
{

    string A = "I am from A";
    public B b; 
    public A
    {
        b = new B();

    }
}

class B
{

    string B = "I am from B";
    public B
    {

    }
    public void Print()
    {
        Console.WriteLine(B);
    }
}

3 つのクラスすべてが同じ exe の場合にクラス A のオブジェクトを作成する方法と、クラス A とクラス B が異なる DLL にある場合に同じオブジェクトを作成する方法を教えてください。

質問の 2 番目の部分に対する 1 つの答えは、インターフェイスを使用し、リフレクションを使用することです。

リフレクションは本当に必要なのか、それとも一種のプログラミング標準なのか。

クラスのオブジェクトを作成するためのベスト プラクティスは何ですか。

4

1 に答える 1

1

インターフェイスは、疎結合を実現する方法を提供します。

再コンパイルや再デプロイさえせずに、事後に機能を拡張または置換する機能を提供したい場合は、基本的に、インターフェースベースの疎結合の上にあるプラグインタイプのアーキテクチャを見ています。

リフレクションを使用してオブジェクトのインスタンスを繰り返し作成することもできますが、もう 1 つのオプションは構成/登録です。たとえば、構成ファイル (またはレジストリなど) で、そのインターフェイスを実装するファイルとクラスを指定し、System.Activator を使用して実行時に作成できます。

例：

http://msdn.microsoft.com/en-us/library/ms972962.aspx

もう 1 つのより堅牢なオプションは MEF です。これは、.net フレームワーク チームによって開発されたプラグイン フレームワークです。

このリンクをチェックしてください：

http://mef.codeplex.com/

そのリンクから（質問を強化します）：

「アプリケーションの要件は頻繁に変化し、ソフトウェアは常に進化しています。その結果、このようなアプリケーションはしばしばモノリシックになり、新しい機能を追加することが困難になります。Managed Extensibility Framework (MEF) は、.NET Framework 4 および Silverlight 4 の新しいライブラリであり、これに対処します。拡張可能なアプリケーションとコンポーネントの設計を簡素化することで、問題を解決します。」

それが役立つことを願っています。

于 2011-09-20T02:15:25.423 に答える