MEF：我应该把CompositionContainer放在哪里？
我一直在使用Windsor IoC Container作为基于Web的应用程序，以解决应用程序应该使用的数据访问层实现。
Web应用程序的UI将由页面组成，每个页面由称为portlet的小单元组成。 （它们的概念有点类似于小部件。）这些所谓的portlet基本上是Web控件，可以在运行时为每个页面进行静态配置。
该应用程序将附带一些内置的，但我希望能够轻松扩展它。
我发现这个机制正是MEF的构建方式。 所以我决定以这样的方式实现系统，即它使用MEF发现portlet。 然后，我意识到它也可以做我目前使用的温莎，所以我决定放弃温莎而不是MEF。
显然，我将不得不使用DirectoryCatalog，它扫描应用程序的bin文件夹中的.dll并返回我需要的所有内容。
我在StackOverflow中阅读了一些有关MEF的教程，示例和所有问题。 我认为使用MEF的最简单方法是通过Glenn Block在其教程中提到的PartInitializer，但我意识到它不在MEF中。 实际上，它是我从CodePlex下载的代码，但是在一个单独的程序集中，并且只在源代码中，而不是以二进制forms。 （这是否意味着它不是MEF的一部分？或者将它放到一个单独的项目中有什么意义？）然后，我意识到它适用于Silverlight，所以它并没有真正帮助我。 （或者我应该只针对.NET 3.5编译它，还是将它包含在我的项目中，我很高兴去？）
所以现在我遇到了以下问题：我应该将CompositionContainer放在我的应用程序中？
还有一件事我想考虑一下：我应该在应用程序的生命周期中只使用一个CompositionContainer，或者我最好在每次需要时创建一个容器？
好问题。
一般来说，关于放置容器的位置的问题，我推荐以下post： http ： //blogs.msdn.com/nblumhardt/archive/tags/Container+Managed+Application+Design/default.aspx
在网络上的MEF中，由于请求/响应性质和可扩展性问题，基于Web的应用程序有点琐碎。 对于Web，您可能希望拥有容器层次结构，一个用于共享的应用程序的根目录，以及每个请求的子contianers。 子容器应该根据请求生存和死亡，以节省资源。 共享容器包含所有呼叫者共享的服务。
您可以查看这些文章，以便更深入地了解如何执行此操作：
http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx http://blogs.msdn.com/hammett/archive/2009/07 /15/mef-and-asp-net-mvc-sample-updated.aspx http://mef.codeplex.com/wikipage?title=Parts%20Lifetime&referringTitle=Guide
至于PartInitializer，我会避免使用类似的东西，除非你必须这样做。 ASP.NET通过HTTP处理程序，模块等在管道中提供了足够的钩子，以便在创建时自动编写。
我在网上使用PI的唯一地方可能是自定义用户控件。 PI作为Silverlight 4的一部分提供，并且在.NET 4.0的框中不可用。 我已经为.NET 4.0创建了一个可用的版本，你可以在这里找到它： http ： //cid-f8b2fd72406fb218.skydrive.live.com/self.aspx/blog/Composition.Initialization.Desktop.zip
HTH Glenn