MEF：我应该把 CompositionContainer 放在哪里？
我一直在基于 Web 的应用程序中使用 Windsor IoC 容器，以解决应用程序应使用的数据访问层实现。
Web 应用程序的 UI 将由页面组成，每个页面都由称为 portlet 的小单元组成。 （它们的概念有点类似于小部件。）这些所谓的 portlet 基本上是 Web 控件，可以在运行时为每个页面单独进行配置。
该应用程序将附带其中一些内置功能，但我希望能够轻松扩展它。
我发现这种机制正是 MEF 的用途。因此，我决定以这样的方式实现该系统：使用 MEF 发现 portlet。然后，我意识到它也可以完成我目前使用 Windsor 的功能，因此我决定放弃 Windsor，转而使用 MEF。
显然，我必须使用 DirectoryCatalog，它会扫描应用程序 bin 文件夹中的 .dll 并返回我需要的所有内容。
我还在 StackOverflow 中阅读了一些教程、示例以及有关 MEF 的所有问题。我认为使用 MEF 最简单的方法是通过 Glenn Block 在他的教程中提到的 PartInitializer，但我意识到它不在 MEF 中。实际上，它位于我从 CodePlex 下载的代码中，但在单独的程序集中，并且仅以源代码形式，而不是以二进制形式。 （这是否意味着它不是 MEF 的一部分？或者将其放入单独的项目有什么意义？） 然后，我意识到它是针对 Silverlight 的，所以它对我没有真正的帮助。 （或者我应该针对 .NET 3.5 进行编译，或者将其包含在我的项目中，然后我就可以开始了？）
所以现在我遇到了以下问题：我应该将 CompositionContainer 放在我的应用程序中的哪里？
我还想考虑另一件事：我应该在应用程序的生命周期中只使用一个 CompositionContainer，还是最好在每次需要时创建一个容器？
I have been using the Windsor IoC Container for my web-based application, to resolve the data access layer implementation the application should use.
The web application's UI will consist of pages, and each page consists of small units called portlets. (Their concept is somewhat similar to widgets.) These so-called portlets are basically web controls and can be configured in runtime for every page invidually.
The application will ship with some of these built-in, but I would like to enable extending it easily.
I figured out that this mechanism is exactly what MEF is built for. So I decided to implement the system in such a way that it discovers portlets using MEF. Then, I realized that it can also do what I currently use Windsor for, so I decided to ditch Windsor in favor of MEF.
Obviously, I will have to use the DirectoryCatalog, which scans for the .dlls in the app's bin folder and returns everything I need.
I read some tutorials, examples, and all questions regarding MEF in StackOverflow, as well. I figured that the easiest way to use MEF is through the PartInitializer which Glenn Block mentioned in his tutorials, but I realized that it is not in MEF. Actually, it is in the code I downloaded from CodePlex, but in a separate assembly, and only in source, not in binary form. (Does this mean that it isn't a part of MEF? Or what's the point in putting it to a separate project?)
Then, I realized that it is for Silverlight, so it doesn't really help me.
(Or should I just compile that against .NET 3.5, or include it in my project, and I'm good to go?)
So now I have a problem which is the following: where should I put the CompositionContainer in my application?
There is another thing I would like to consider: should I use only one CompositionContainer in the lifetime of the app, or I'm better off creating a container for every time when I need it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好问题。
一般来说，关于容器放置位置的问题，我推荐以下帖子：http://blogs.msdn.com/nblumhardt/archive/tags/Container+Managed+Application+Design/default.aspx
在 Web 上的 MEF 中，基于 Web 的应用程序由于请求/响应性质和可扩展性问题，有点棘手。对于网络，您可能希望有一个容器层次结构，一个根容器用于共享的应用程序，以及每个请求的子容器。为了节省资源，子容器应该随请求而生或死。共享容器包含由所有调用者共享的服务。
您可以查看这些文章以更深入地了解如何执行此操作：
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
格伦
Good questions.
In general in terms of questions about where to put the container, I recommend the following posts: http://blogs.msdn.com/nblumhardt/archive/tags/Container+Managed+Application+Design/default.aspx
In of MEF on the web, web-based apps are a bit tricker because of the request / response nature and scalability concerns. For web you would likely want to have a hierarchy of containers, one root one for the application which is shared, as well as child contianers per-request. The child containers should live and die with the request in order to conserve resources. The shared container contains services that are shared by all callers.
You might check out these articles for more insight into how to do this:
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
As far as PartInitializer, I would avoid using something like it unless you have to. ASP.NET provides sufficient hooks in the pipeline through HTTP Handlers, modules and such to let automatically compose on creation.
The only place i would see using PI on the web would be possibly within a custom user control. PI ships as part of Silverlight 4 and is not available in the box for .NET 4.0. I have created a usable version for .NET 4.0 which you can find here: http://cid-f8b2fd72406fb218.skydrive.live.com/self.aspx/blog/Composition.Initialization.Desktop.zip
HTH
Glenn