c# – MEF最佳实践：在应用程序中我创建容器的位置以及调用Compose()的位置？

概述我已经决定使用MEF作为我拥有的插件模式,并且发现MEF易于拾取而且根本没有侵入性.我查看了样品,发现它们非常容易使用. 然而,一旦开始实施,我开始苦苦于构图.假设我有一个在其中一个属性上有[ImportMany]的类.我看到的所有例子中,他们在具有导入的类中创建了Container(让我们称之为可组合的),并且基本上该类组成了自己.对于一个例子来说这可能是好的,但是确定地知道插件如何被填充对于组 我已经决定使用MEF作为我拥有的插件模式,并且发现MEF易于拾取而且根本没有侵入性.我查看了样品,发现它们非常容易使用.

然而,一旦开始实施,我开始苦苦于构图.假设我有一个在其中一个属性上有[importMany]的类.我看到的所有例子中,他们在具有导入的类中创建了Container(让我们称之为可组合的),并且基本上该类组成了自己.对于一个例子来说这可能是好的,但是确定地知道插件如何被填充对于组合物来说知道太多了.

我可以愉快地创建一个单例容器并在我的可编组中访问它,但是另外,composable必须在其自身上显式调用Compose()并且我对此不满意,因为它就像一个依赖注入场景,类主动调用在容器上解析().所以我不想将它用于服务定位.

为了使事情变得更糟,我也使用温莎城堡进行DI,我不确定MEF和Windsor如何一起工作.

我真的环顾四周,无法找到任何有关如何正确做MEF的指导和样本.现在可能是我没有环顾四周或者我不太了解MEF(这是真的)但是会从实际在现实世界中使用它的经验中重视你的观点.

解决方法 不要那样做.我在上一个项目中使用了MEF,我希望不要这样做.

背后有一个好主意(组合),我多年来一直在手动做.我很高兴.NET 4.0中的第一个正式版本,但仍然存在很多设计问题.

不幸的是,将测试和错误发现留给最终用户并反馈来之不易的错误和建议是微软政策的一部分.

如果您使用示例所示的方式,MEF是很好的.一旦你需要一点改变,你会发现没有足够的文档,没有人会回答你.以下是我在MEF中未解决的一些问题,您可以在codeplex.com中找到我的问题,这些问题从未得到开发团队的回答：

1)如何将参数传递给零件的构造函数(他们可能会说使用在Codeplex版本中提供的ExportFactory,但是我浪费了很长时间在此,我可以说没有可接受的解决方案)

2)如何设置零件配置？ (我最终通过一种不好的方法将配置传递给零件,但最好的可用)

3)MEF非常慢,因为它在引擎盖下使用反射.对于我的情况,加载1,000个零件需要60秒.

4)调试很棒.你得到的消息不清楚.您将最终从codeplex下载完整的源代码并在代码中搜索您的异常.

毕竟我认为如果你有其他选择,让MEF成熟并使用下一个版本.

我只是分享了自己的经验.

总结

以上是内存溢出为你收集整理的c# – MEF最佳实践：在应用程序中我创建容器的位置以及调用Compose()的位置？全部内容，希望文章能够帮你解决c# – MEF最佳实践：在应用程序中我创建容器的位置以及调用Compose()的位置？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。