Prism6下的MEF：第一个Hello World
来源：博客园
最近看书比较多，正好对过去几年的软件开发做个总结。写这个的初衷只是为了简单的做一些记录。前言复杂的应用程序总是面临很多的页面之间的数据交互，怎样创建松耦合的程序一直是多数工程师所思考的问题。诸如依赖注入，PubSub模式，MVVM等概念，都致力于帮助我们创建更加松耦合易于维护的程序，也有不少框架实现了这些功能，Prism就是其中一个。Prism是微软的实践和模式小组写的一套框架，包含了常用的依赖注入方式（Autofac，Mef，Ninject，StructureMap，Unity），MVVM，数据校验，基于PubSub的消息模型，导航，插件管理等等功能，能够帮助我们创建伸缩性好，耦合度低的程序。下面我们开始尝试从一个普通的WPF程序开始，将它改造成一个使用Prism框架的程序。开发环境Windows 10 10586Visual Studio 2015.Net Framework 4.6.1Prism 6新建PrismSample项目因为希望能够进行插件式的开发，所以IoC容器选择了MEF。新建一个WPF项目，命名为PrismSample。然后我们需要从nuget导入三个包：我们先将Prism.Core，Prism.Mef，Prism.MVVM添加进来。添加完之后，我们需要将我们的MainWindow删除掉，因为我们希望实现自己的主页面。当然，在App.xaml文件中也要做修改：&Application x:Class="PrismSample.App"
xmlns="/winfx/2006/xaml/presentation"
xmlns:x="/winfx/2006/xaml"
xmlns:local="clr-namespace:PrismSample"&
&Application.Resources&
&/Application.Resources&&/Application&这时候，我们的项目是无法正常启动的。接下来我们要新建一个Shell页面，作为我们的主页面。新建PrismSample.Infrastructure.Abstract新建一个类库项目，将其命名为PrismSample.Infrastructure.Abstract，并建立如下结构的文件：为了创建IViewModel接口和ViewModelBase的抽象类，我们需要先从nuget中引入Prism.Mvvm。当我们添加完后，实现文件内容如下：namespace PrismSample.Infrastructure.Abstract.Presentation.Interface{
public interface IViewModel
IView View { }
}}using Microsoft.Practices.Prism.Musing PrismSample.Infrastructure.Abstract.Presentation.Inamespace PrismSample.Infrastructure.Abstract.Presentation.AbstractClass{
public abstract class ViewModelBase : BindableBase, IViewModel
public IView View { }
}}在PrismSample中实现内容新建Shell页面添加页面Shell：&Window x:Class="PrismSample.Shell"
xmlns="/winfx/2006/xaml/presentation"
xmlns:x="/winfx/2006/xaml"
xmlns:d="/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:local="clr-namespace:PrismSample"
mc:Ignorable="d"
Title="Shell" Height="300" Width="300"&
&TextBlock Text="{Binding Text}" HorizontalAlignment="Center" VerticalAlignment="Center"/&
&/Grid&&/Window&using Microsoft.Practices.Prism.Musing System.Wnamespace PrismSample{
[Export("ShellView", typeof(IView))]
public partial class Shell : Window, IView
public Shell()
InitializeComponent();
}}新建Shell的ViewModelusing PrismSample.Infrastructure.Abstract.Presentation.Iusing Microsoft.Practices.Prism.Musing PrismSample.Infrastructure.Abstract.Presentation.AbstractCnamespace PrismSample{
[Export("ShellViewModel",typeof(IViewModel))]
public class ShellViewModel : ViewModelBase
private string _
public string Text
get { return _ }
set { SetProperty(ref _text, value); }
[ImportingConstructor]
public ShellViewModel([Import("ShellView", typeof(IView))]
IView view)
this.View =
this._text = "Hello World";
this.View.DataContext =
}}新建Bootstrapper类using Prism.Musing PrismSample.Infrastructure.Abstract.Presentation.Iposition.Husing System.Wnamespace PrismSample{
public class Bootstrapper : MefBootstrapper
protected override DependencyObject CreateShell()
IViewModel shellViewModel = this.Container.GetExportedValue&IViewModel&("ShellViewModel");
return shellViewModel.View as DependencyO
protected override void InitializeShell()
Application.Current.MainWindow = (Shell)this.S
Application.Current.MainWindow.Show();
protected override void ConfigureAggregateCatalog()
base.ConfigureAggregateCatalog();
//加载自己
this.AggregateCatalog.Catalogs.Add(new AssemblyCatalog(this.GetType().Assembly));
}}修改App.xaml.cs文件using System.Wnamespace PrismSample{
public partial class App : Application
protected override void OnStartup(StartupEventArgs e)
base.OnStartup(e);
Bootstrapper bootstrapper = new Bootstrapper();
bootstrapper.Run();
}}最后的文件结构和运行结果小结本篇通过一个简单的应用建立了一个基于Prism的包含Ioc和Mvvvm的小程序，虽然是个小程序，但包含了Prism的精髓--组合。参考信息
免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动Unity/MEF/Prism最近研究Prism4看的云里雾里的各位给解释下Prism4中的MEF和Unity到底差别在哪里？如果我想实现模块化、界面逻辑分析、可扩展的应用程序，是不是只用MEF或者Unity加个MVVM模式之类的就可以了？那prism用来干嘛？
回答1：没有研究过Prism4...
回答2：纯顶。。。我学的东西还是太少了。。
还没接触过，就只知道Unity是个依赖注入的容器。。。
回答4：神马东瞎啊。。。。没玩过
szyrainbow
Unity vs MEFUnity is mostly used for static dependencies and is more an “internal” technology, meaning outsiders do not need to know that unity is being used in the application.MEF should be used for dynamic dependencies, it is grate at dynamically loading components and with the use of attributes it make creating application extensions or an application that can be extended by others easy and streamlined.
szyinshengjun
回答6：没有研究过MEF vs. Unity in composite application (Prism) | Akash Kava
This article describes differences between MEF and Unity which may help you in deciding which technology you must use while making composite application.
Both technologies are useful and easy to understand, and offer a rich set of features that can make integration of various software components very easy. However, both being little different in functioning they offer exact same level of features but choosing wrong one can lead to chaos.
So we will drill down to differences between their operations.
Unity creates new instance of type by default.
MEF creates singleton instance of type by default.
Unity does not require registration for classes. This means you can instantiate any other third party type.
MEF requires Export attribute to be specified on the class. MEF cannot create instance of third party type unless it defines Export.
Unity requires type registration in code for interface types.
No registration, simple Export attribute does it all.
Unity container can compose IUnityContainer property in the composed class where you can further access it easily in your own scope. This behavior is not useful for Plugin architecture as getting access to IUnityContainer may result in full access to your application.
MEF does not allow composition of CompositionContainer, which blocks access to MEF in your own scope if you do not have CompositionContainer. This is useful in Plugin architecture where third party code has limited access to your application.
Unity offers injection method mechanism, that can define IUnityContainer parameter and get the unity container object, with which you can compose other private properties manually.
MEF can only compose public properties, this is dangerous as anyone can change public property and make application crash easily.
Inside your application’s framework code, Unity serves the best as it gives you full control over type hierarchy, lifecycle and allows you to utilize third party components easily without writing much of code.
Inside your application, MEF will put lots of restrictions in which your framework can operate as it cannot easily compose third party components and it will force you to write numerous attributes in your code without which it will fail drastically.
Mostly, User Interface objects like your View, or UserControl or any UIElement can never be shared as no UIElement can have two parents at same time. So default behavior of Unity to create a new instance of type is very helpful.
Default behavior of MEF will create only one single instance of UI object, that will lead to trouble, not only that, if UI object is third party tool, MEF will not compose it. You can create multiple copies of exported type by specifying one more attribute called [PartCreationPolicy(Shared)], however it is very time comsuming and tedious to define this one every UI related type we create.
Unity does allow singleton objects, but for that you have to register an instance to the container.
MEF by default creates singleton object only.
Unity does not allow multiple registrations for same instance in same scope sharing same interface but different type.
MEF allows multiple singleton objects of different type sharing same interface.
Unity works best for MVVM, as composing user interface parts can be very easy with unity.
MEF does not work great with MVVM as it will create singleton objects that will behave strangely in runtime and lead to UI failure.
Unity is not good for Modularity, as composing IUnityContainer will offer more control of unity lifecycle to third party modules.
MEF is good for Modularity, as it will not allow modification of composition thus offering great deal of security between modules.
So, to develop a framework, MVVM Crud application and a UI framework, Unity is the best.
To expose some functionality of your application for third party modules to register and access limited functionality, MEF is the best.
Following is outline of how your application should be,
Unity Container must compose and manage your application’s framework, UI and MEF modules.
MEF will only expose limited functionality from Unity Container to third party modules.
No module, through MEF should have access to unity container at all.
Thank you for reading this article, please put your suggestions below in the comment. I do not intend to make any specific rules and regulations here but I am suggesting the architecture based on the differences I have outlined.
Your article is inaccurate. Apparently you have a lot more experience and bias to Unity, and your conclusion is incorrect. It’s not that the conclusion should be different – both Unity and MEF have your place – but making it look like an objective decision is misleading because it is truly a subjective choice based on familiarity with the tools.
MEF does not require the export attribute. You can apply an inherited export to an interface for implicit exports, and you can also write a custom export provider that is not attribute-based.
MEF does not have to compose public properties. You can use an importing constructor and keep the composed properties private.
Your idea that MEF forces you to use attributes is simply wrong. There are plenty of examples of fluent and even convention-based MEF that requires minimal to no configuration. MEF also gives you full contorl over lifetime management.
MEF’s default is singleton but this is easily overridden, the same way you mention that Unity is easily overridden to provide singleton.
I don’t know where you can qualify that MEF works terribly for MVVM. We write tons of enterprise line of business applications using MVVM and MEF. I have a framework based on MEF because it is so helpful for MVVM. If you are getting “strange runtime/UI failures” it is from your lack of knowledge/experience, not a limitation of MEF.
Leave a Reply
Categories&
&Business&
Just For Fun&
Music Learning&
Stay In Touch
Thanks for dropping by! Feel free to join the discussion by leaving comments, and stay updated by subscribing to the .
(C) 2010 Akash Kava}