4

一連のプラグインをホストするアプリを作成しています。これらのプラグインは通常、2 つのライブラリ.Commonを使用し、プラグインが実装する必要があるインターフェイスなど.UIを含みます。

現在、プラグインをライセンス対象にする機能を追加している段階です。ILicenseInfoProviderインターフェイス インスタンス ( ) を定義し、MEF を介してエクスポートするプラグインのみをロードするように、ホスト アプリケーションを変更しました。そのビットは大丈夫です。

ライセンス コードの選択されたプロバイダーがあり、そのライセンス システムにはライブラリの使用が含まれます。ここで、各プラグインがそのシステムを通じてライセンスされることを強制したくありません。さらに、そのシステムのアセンブリへの参照を必要とします。そのため、サードパーティのライブラリを参照するコードを独自のアセンブリ (のようなもの.Licensing.Vendor) に入れることを計画しています。このようにして、プラグインはそのアセンブリへの参照を追加するだけで、次のようなクラスを含めることができます。

[Export(typeof(ILicenseInfoProvider))]
class MyAssemblyLicenseInfoProvider : BaseVendorLicenseInfoProvider
{ 
    public MyAssemblyLicenseInfoProvider() : base("My Assembly's Product Name")
}

私はその設定にかなり満足しています.1つの厄介なことを除けば、アセンブリには使用中の特定のライセンスシステムに関連する.Licensing.Vendor単一のクラスしか含まれないということです.BaseVendorLicenseInfoProvider

結局のところ、私の質問は非常に単純です。

そのクラスを独自のアセンブリに配置するのはやり過ぎに思えますか?それとも、すべてのプラグインにサードパーティ ライブラリへの参照を強制的に保持させないことの利点は価値がありますか?

4

3 に答える 3

3

現時点では、このアセンブリには適切な目的があります。それは、サードパーティがライセンスを介して対話する手段を提供するための公に見えるアセンブリです。私には完全に合理的なようです：

  • 現在は 1 つのクラスしかなくても、将来はさらに多くのクラスが存在する可能性があります
  • 公開されているため、必要なものだけを提供したい
  • 特定の実装を強制することなく、合理的なレベルの責任、つまりライセンスをカプセル化します。
于 2012-06-22T10:04:39.033 に答える
2

いいえ、やり過ぎではありません。一部のプラグインはライセンスを必要としない場合があり、一部のプラグインは必要な場合があります..

于 2012-06-22T10:00:23.553 に答える
1

それはあなたが何を達成しようとしているかによって異なります。アセンブリはコードを物理的に分離する方法ですが、名前空間はコードを論理的に分離する方法です。

あまりにも多くのアセンブリをロードするとパフォーマンスがわずかに低下する可能性があることを考えると (これは、少数ではなくかなりの数を意味します)、できるだけ多くのアセンブリを 1 つのアセンブリにグループ化して分離することが可能かどうかを検討できると思います。それらは名前空間によって。しかし、他のすべてのものから完全に分離しておくことが本当に理にかなっていると感じた場合は、それBaseVendorLicenseInfoProviderも問題ではないと思います.

結局のところ、自分が正しいと感じることがすべてです。もちろん、誰もが自分の意見を持っていますが、自分の持っているものが自分に合っている限り、問題はないと思います。

于 2012-06-22T10:06:09.083 に答える