Question

我正在编写一个可以播放一系列插件的应用程序。这些插件通常使用两个库.Common和.UI，其中包含插件需要实现的接口等。

我现在正处于添加插件许可权限的程度。我修改了我的主机应用程序，以便它只加载定义接口实例（ILicenseInfoProvider）的插件并通过MEF导出它。这一点很好。

我们有一个选定的许可代码提供商，其许可系统涉及使用库。现在，我不想强制每个插件通过该系统获得许可，并且，通过扩展，需要引用该系统的程序集。因此，我计划将引用第三方库的代码放在其自己的程序集中（类似.Licensing.Vendor）。这样插件就可以简单地添加对该程序集的引用，并包含一个看起来像这样的类：

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

我对这个设置感到相当满意，除了一个琐碎的事情 - 这是.Licensing.Vendor程序集只包含一个类，这是与BaseVendorLicenseInfoProvider相关的正在使用的特定许可证制度。

所以，毕竟，我的问题非常简单：

将该类放入其自己的程序集中是否显得过于苛刻，或者不强制所有插件持有对第三方库的引用是否值得呢？

Answer 1

目前有一个适合组装的目的 - 为第三方提供公开可见的程序集，以提供通过许可进行交互的方法。对我来说似乎很合理：

即使目前只有一个班级，将来可能会有更多班级
它是公开可见的，因此您只想提供必要的
它包含了合理的责任，即许可，而不强制执行具体的实施

Answer 2

我投反对票，它不是矫枉过正，有些插件可能不需要许可证，有些可能会这样做..

Answer 3

这取决于你想要达到的目标。程序集是物理分隔代码的一种方式，而命名空间是逻辑分隔代码的一种方式。

鉴于加载太多组件可能会有轻微的性能损失（我指的是一个很大的数字，而不仅仅是少数几个），那么我想你可以考虑是否可以将尽可能多的组合成一个程序集，但按名称空间分隔它们。但如果你觉得让BaseVendorLicenseInfoProvider完全与其他所有事物分开是有意义的话，那么我也不认为这是一个问题。

在一天结束时，关于你的感觉是对的，当然每个人都有自己的看法，但只要你有什么对你有用，那么我就看不到了问题

是一个包含单个类矫枉过正的程序集吗？

3 个答案: