自己的可扩展层或 MEF/MAF？
对于那些在 .NET 中使用应用程序可扩展性的人来说，您更喜欢做什么 - 创建自己的可扩展性层还是使用 MEF（托管可扩展性框架）或 MAF（托管外接程序框架）？
到目前为止，我已经使用了两种实现应用程序可扩展性的方法，并且我喜欢 MEF，因为它可以更轻松地从特定位置加载现有程序集，而无需直接验证接口实现（因为缺少 ImplementationOf(接口）签入.NET）。
您认为特定的可扩展层首选项有哪些优点？有什么缺点？
For those that work with application extensibility in .NET, what do you prefer doing - creating your own extensibility layer or using MEF (Managed Extensibility Framework) or MAF (Managed Add-in Framework)?
So far, I've used both ways of implementing application extensibility and I like MEF for the fact that it makes it easier to load existing assemblies from a specific location without directly verifying for interface implementations (for the lack of an ImplementationOf(interface) check in .NET).
What are the advantages that you see in your specific extensibility layer preference? What are the disadvantages?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MEF 当然有很多优点，其中大部分是您提到的……可扩展性、模块化、生命周期管理以及我希望在一流框架中提供的任何其他功能。它也随框架一起提供，因此无需执行任何额外操作，并且您知道它在各个实现中都是一致的。
它在 VS 2010 中使用，因此不可能有更广泛使用的现实世界示例。
MAF实际上并不是同一件事。它是针对 System.AddIn 的，并且有一些更严格的要求和契约需要满足。话虽如此，它还专门针对某些人可能想要的特定类型的可扩展性。
如果我的占地面积非常小或应用程序不需要所有额外的开销，我只会采用自定义方法。
MEF certainly has a lot of advantages, most of what you mentioned ... extensibility, modularity, lifetime management, and anything else I'd want available in a first class framework. It also is shipped with the framework, so there's nothing exta to do and you know it will be consistent across implementations.
It's used in VS 2010 so there couldn't be a more broadly used real world example in play.
MAF isn't really the same thing. It is very specific to System.AddIn and has some more rigid requirements and contracts to satisfy. Having said that, it also specifically targets a particular type of extensibility that some people may want.
I would only go for a custom approach if I had a really small footprint or application that just didn't need all of the additional overhead.