插件框架 - 插件程序集是否过多？
我正在开发的产品需要以这样的方式构建：我们有一个由可插入框架驱动的报价引擎。
我们目前正在考虑使用 MAF，因此我们可以利用主机和插件接口的分离来进行版本控制。
然而，我担心我们会有很多程序集，很可能我们每个报价引擎插件都有一个程序集 - 其中可能有 100 个，我们还需要支持多个版本，所以可能会有总共有很多组件。
报价引擎还使用 WF 来驱动它，这意味着每个插件的每个 AppDomain 都需要一个与其关联的工作流运行时。这看起来相当重量级，但是我们可以卸载不常用的插件。
这看起来是一个很好的设计吗？我们还研究了使用 IOC 容器加载插件类型的单个 AppDomain 解决方案，但我担心考虑到其数量，我们将无法卸载任何程序集。
The product I'm working on needs to be built in such a way that we have a quote engine driven by a pluggable framework.
We are currently thinking of using MAF, so we can leverage separation of the host and addin interfaces for versioning.
However, I'm concerned that we'd have lots of assemblies, it's likely that we'd have one for each quote engine addin - of which there could be 100 going forward, we also need to support multiple versions, so there could be lots of assemblies in total.
The quote engine also uses WF to drive it, which means each AppDomain for each addin will need a workflow runtime associated with it. This seems quite heavyweight, however we can unload unfrequently used addins.
Does this seem like a good design? We've also looked at a single AppDomain solution using an IOC container to load addin types, but I'm concerned that we won't be able to unload any of the assemblies, given their quantity.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
每个 AppDomain 和 Assembly 确实会增加一些开销，但我不知道有任何具体限制。
您唯一可以做的就是测试（例如，通过编写代码来生成许多非常相似但不同的程序集，以尝试使用 100、250、1000，...）并查看影响是什么）。
Each AppDomain and Assembly does add some overhead, but I'm not aware of any specific limits.
The only thing you can do is test (e.g. by writing code to generate many very similar, but different, assemblies to try working with 100, 250, 1000, ....) and see what the impact is).