1

いくつかのレガシー コードを調べると、ソース コードが利用可能な dll をロードするためにリフレクションを使用しているコードに遭遇しました (それらはソリューション内の別のプロジェクトでした)。

なぜこのように行われたのかを突き止めようと頭を悩ませていました（当然、コードは文書化されていませんでした...）。

私の質問は、アセンブリを参照するのではなく、リフレクションを介してアセンブリをロードすることを好む正当な理由を考えてもらえますか?

4

3 に答える 3

1

はい、実行時の条件に応じて異なる DLL をロードする必要がある動的モジュール システムがある場合。私が働いている場所ではこれを行っています。システムにロードされる可能性のあるさまざまなオプション モジュールのライセンス チェックを行い、ライセンスがチェックアウトされた場合にのみ、各モジュールに関連付けられた DLL をロードします。これにより、決して実行されるべきではないコードが読み込まれるのを防ぎ、パフォーマンスをわずかに向上させ、バグを防ぐことができます。

DLL を動的にロードすると、ソース コードを変更せずに機能を大幅に変更できる場合もあります。メイン アセンブリは、たとえば、何らかのインターフェイスを実装するすべてのクラスを検出し、実行時の基準に応じて使用するクラスを選択する検出プロセスを開始する場合があります。

最近では、通常、この種のタスクにMEFを使用したいと思うでしょうが、それは .NET 4.0 以降でしかないため、手動でそれを行う多くのコードベースがおそらく存在します。(私は MEF についてあまり知りません。おそらく、この部分も手動で行う必要があります。)

とにかく、あなたの質問に対する答えは、リフレクションを使用して DLL を動的にロードする十分な理由があるということです。それがあなたの場合に当てはまるかどうかは、詳細なしでは言えません。

于 2013-09-17T07:09:54.257 に答える
1

特定のプロジェクトを知らなくても、あなたのケースでなぜそのように行われたのか、誰も教えてくれません。

しかし、一般的な理由は次のとおりです。

  • 更新可能性: アプリケーション全体を再コンパイルして置き換えるのではなく、更新されたライブラリを単純に再コンパイルして置き換えることができます。

  • 協力: インターフェースが明確であれば、複数のチームが協力して作業できます。1 つはメイン アプリケーション用、もう 1 つは dll 用

  • 再利用性: 複数のプロジェクトで同じ機能が必要な場合があるため、同じ dll を何度も使用できます。

  • 拡張性: 場合によっては、出荷時には存在しないプラグインを使用して後でプログラムを拡張できるようにしたい場合があります。これは、dll を使用して実現できます。

これがセットアップの一部を理解するのに役立つことを願っています..

于 2013-09-17T07:10:10.890 に答える
0 
Reason for loading an assembly via reflection rather than referencing it?

DoWork()このメソッドが返すメソッドを持つ 3 つのクラスがありstring、条件 (厳密な型) をチェックしてアクセスしているシナリオを考えてみましょう。

これで、2 つの異なる DLL にさらに 2 つのクラスができました。この変更にどのように対処しますか?

1)reference新しい DLL を追加し、条件チェックを変更して動作させることができます。

2) を使用reflectionして、実行時に条件とアセンブリ名を渡すことができます。これにより、プライマリ アプリケーションのコードを変更することなく、実行時に任意の数の機能を追加できます。

于 2013-09-17T07:35:03.057 に答える