在Prism应用程序环境中Unity和MEF?

时间:2015-08-10 13:38:56

标签: mvvm architecture unity-container prism mef

我正在寻找使用PRISM创建我的第一个应用程序,我下载了它(V5),我已经准备好了,但仍然有些事情让我烦恼。

Unity或MEF。

如果我选择一个与另一个相比,有什么我不能做的事情吗?

我的意思是,我检查了PRISM提供的两个快速启动示例,在我看来这只是一个品味问题。

我在互联网上搜索,大多数页面都说Unity不能发现模块等,但是(据我所知),在Prism应用程序的情况下,Prism为Unity做了这个。

所以我的最后一个问题:   - 选择Unity或MEF只是一个问题"品味",或者是否真的有某些东西(限制,功能,易用性)应该让我选择其中一个?

非常感谢

1 个答案:

答案 0 :(得分:18)

Unity 默认情况下会创建新的类型实例。

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

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

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

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

MEF 无需注册,简单的“导出”属性就可以完成所有操作。

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

MEF 不允许使用CompositionContainer的组合,如果您没有CompositionContainer,它会阻止您自己范围内的MEF访问。这在插件架构中很有用,其中第三方代码对您的应用程序的访问权限有限。

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

MEF 只能组成公共属性,这很危险,因为任何人都可以更改公共财产并轻松地使应用程序崩溃。

在应用程序的框架代码中,Unity提供最佳服务,因为它可以完全控制类型层次结构,生命周期,并允许您轻松地使用第三方组件而无需编写大量代码。

在你的应用程序中,MEF会对你的框架进行很多限制,因为它不能轻易地组成第三方组件,它会强迫你在你的代码中编写很多属性,否则它们就会大大失败。

大多数情况下,您的View,UserControl或任何UIElement之类的用户界面对象永远无法共享,因为UIElement不能同时拥有两个父级。因此,Unity创建新类型实例的默认行为非常有用。

MEF的默认行为将只创建一个UI对象的单个实例,这将导致麻烦,不仅如此,如果UI对象是第三方工具,MEF将不会组成它。您可以通过另外指定一个名为[PartCreationPolicy(Shared)]的属性来创建导出类型的多个副本,但是,我们创建的每个UI相关类型都定义了这个属性,这是非常浪费时间和繁琐的。

Unity确实允许使用单例对象,但为此必须将实例注册到容器中。

默认情况下,

MEF 仅创建单个对象。

Unity 不允许同一个范围内的同一个实例共享同一个界面但类型不同的多个注册。

MEF 允许多个不同类型的单个对象共享相同的界面。

Unity 最适合MVVM,因为组合用户界面部件可以很容易统一。

MEF 对MVVM不起作用,因为它会创建单个对象,这些对象在运行时会表现得很奇怪并导致UI失败。

Unity 不利于Modularity,因为编写IUnityContainer将为第三方模块提供更多的统一生命周期控制。

MEF 适用于Modularity,因为它不允许修改成分,从而在模块之间提供了很大的安全性。

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

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