Mvvm 在Prism应用程序的背景下，Unity vs MEF？

我想用PRISM创建我的第一个应用程序，我下载了它（V5），我已经准备好了，但是仍然有一些东西困扰着我

统一或MEF

如果我选择其中一个或另一个，有什么我不能做的吗

我的意思是，我检查了PRISM提供的两个快速入门示例，在我看来，这只是一个品味问题

我在互联网上搜索过，大多数页面都告诉Unity无法发现模块等等，但是（据我所知），在Prism应用程序的情况下，Prism为Unity这样做

因此，我的最后一个问题是： -选择Unity或MEF只是一个“品味”的问题，还是真的有什么东西（限制、功能、易用性）让我选择其中一个

---

非常感谢

Unity默认创建类型的新实例

MEF默认情况下创建类型为的单例实例

Unity不需要注册课程。这意味着您可以实例化任何其他第三方类型

MEF要求在类上指定导出属性。MEF无法创建第三方类型的实例，除非它定义了导出

Unity要求在代码中为接口类型注册类型

MEF无需注册，简单的导出属性即可完成所有操作

Unity容器可以在组合类中组合IUnityContainer属性，您可以在自己的范围内轻松地进一步访问它。此行为对于插件体系结构不有用，因为访问IUnityContainer可能导致完全访问您的应用程序

MEF不允许组合CompositionContainer，如果您没有CompositionContainer，它会阻止您在自己的范围内访问MEF。这在插件体系结构中非常有用，因为第三方代码对应用程序的访问受到限制

Unity提供了注入方法机制，可以定义IUnityContainer参数并获取Unity容器对象，您可以使用该对象手动组合其他私有属性

MEF只能组合公共属性，这是危险的，因为任何人都可以更改公共属性并使应用程序很容易崩溃

在应用程序的框架代码中，Unity是最好的，因为它可以让您完全控制类型层次结构和生命周期，并允许您轻松利用第三方组件，而无需编写大量代码

在您的应用程序内部，MEF将对您的框架的运行施加很多限制，因为它不能轻松地组成第三方组件，并且它将迫使您在代码中编写大量属性，否则它将彻底失败

大多数情况下，像视图、用户控件或任何UIElement这样的用户界面对象都不能共享，因为任何UIElement都不能同时有两个父元素。因此，创建类型的新实例的Unity默认行为非常有用

MEF的默认行为将只创建一个UI对象实例，这将导致麻烦，不仅如此，如果UI对象是第三方工具，MEF将不会组合它。您可以通过指定另一个名为[PartCreationPolicy（Shared）]的属性来创建导出类型的多个副本，但是在我们创建的每个UI相关类型中定义这个副本非常耗时且繁琐

Unity确实允许单例对象，但为此，您必须向容器注册一个实例

MEF默认情况下仅创建单例对象

Unity不允许对同一范围内共享相同接口但类型不同的同一实例进行多次注册

MEF允许多个不同类型的单例对象共享同一接口

Unity最适合MVVM，因为使用Unity编写用户界面部件非常容易

MEF不能很好地与MVVM配合使用，因为它会创建在运行时行为异常的单例对象，并导致UI故障

Unity不利于模块化，因为组合IUnityContainer将为第三方模块提供对Unity生命周期的更多控制

MEF有利于模块化，因为它不允许修改组合，因此在模块之间提供了很大的安全性

因此，要开发框架、MVVM Crud应用程序和UI框架，Unity是最好的

---

为了向第三方模块公开应用程序的某些功能，以注册和访问有限的功能，MEF是最好的。

我读到的可能的副本在PRISM案例中，我们主要需要DI库，MEF与DI无关，所以我应该使用Unity或任何其他DI库，是真的吗？我读得越多，我就越觉得Unity更适合，而在MEF更好的地方，prism是用来缩小差距（模块发现）的，你不会相信你从中获得答案的博客（逐字）？