何时使用 MEF
我尝试了 Unity 和 MEF 以及普通的旧新。我对什么时候需要使用这些“模式”感到有点困惑。如果使用new更简单并且能满足我的需求，为什么我会选择使用MEF或Unity呢？
换句话说，什么需要证明使用 MEF 或 Unity 是合理的？
I tried Unity and MEF and plain old new. And I am a bit confused as to when exactly you need to use any of these "patterns". Why would I choose to use MEF or Unity if using new is simpler and satisfies my needs.
In other words, what needs justify the use of MEF or Unity?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MEF 允许隔离应用程序内的子系统。如果您需要经常甚至在运行时更改子系统实现，这种隔离非常有用。 MEF 负责加载子系统并将所有提供者连接到适当的消费者的细节。这是朝着通过连接一组彼此一无所知的独立模块来构建应用程序的理想迈出的一大步。
传统应用程序中的很大一部分代码专门用于简单地将事物粘合在一起 - 粘合代码。 MEF 极大地减少了对粘合代码的需求。
如果您只是构建一个对象以便可以打开文件或显示对话框，那么这不是 MEF 的用途。如果您想要编写使用通用 xyz 服务的代码，但不想对供应商 a 或供应商 b 实现进行硬编码，那么这可能是 MEF 候选者。
MEF allows for isolation of subsystems within an application. This isolation is useful if you need to change subsystem implementations often, or even at runtime. MEF takes care of the details of loading the subsystems and wiring up all the providers to the appropriate consumers. It's a giant step forward toward the ideal of building an application by concatenating a set of self-contained modules that know nothing about each other.
A significant portion of the code in a traditional application is dedicated to simply gluing things together - glue code. MEF drastically reduces the need for glue code.
If you're just constructing an object so you can open a file or show a dialog, that's not what MEF is for. If you're wanting to write code that uses a generic xyz service but don't want to hard-code a dependency on vendor a or vendor b implementations, that might be a MEF candidate.