九月初，微软在CodePlex推出了
Managed Extensibility Framework
http://www.codeplex.com/MEF
托管扩展性框架是什么？
“托管扩展性框架（Managed Extensibility Framework，简称MEF），是.NET的一个新的类库，旨在促成应用和组件更大的重用。通过使用MEF，.NET应用将能从是静态编译的而变成可动态组合的。如果你正在建造可扩展的应用，可扩展的框架和应用扩展，那么MEF就可为你所用。”
今年早些时候，微软成立了一个应用框架核心开发团队（Application Framework Core team），其宗旨是在应用框架空间（WinForms, ASP.NET, WPF, Silverlight）起和基础类库（BCL）开发团队在平台底层方面一样的作用。
基础类库开发团队在负责平台底层层次上减少重复和提供共同的抽象诸多方面起了很大的作用，但在高层次方面微软还没有类似团队负责处理同类问题。于是乎，造成了一些不幸的重复（譬如每个应用模型都有若干个数据绑定模型，WPF和WF有着不同的依赖属性系统），且在应用模型代码方面缺乏共同的抽象。
于是应用框架核心开发团队就应运而生了。
这个团队的第一个具体项目就是“托管扩展性框架（MEF）”，他们发现，在.NET框架本身以及日趋托管的应用（象Visual Studio）中越来越多的地方，需要提供或者已经提供了钩子（hook），可为第三方扩展所用。譬如使用TraceSource API的TraceListener插件，Visual Studio代码分析的可插拔规则等等。
但在不存在一个内置的扩展性框架的情形下，如果开发人员想要提供这样的扩展，只好通过提供定制的机制来实现，于是造成重复劳动。他们希望MEF可以中止这样的重复，在框架和应用中鼓励以及促成建立在MEF之上的更多的扩展性。
六月初，他们推出了第一个CTP版本，九月份的这个版本是第二个版本。该版本包括完整的框架代码，还有三个例程(类似Outlook客户端的MEFlook，类似Tetris，形状可通过插件形式扩展的游戏MEFTris，以及可扩展的文件管理器）。
MEF与IoC容器的区别
从表面上，MEF有点类似IoC容器，但MEF并不是IoC容器。在这一点上，很多人都很困惑。
Oren Eini在他的博客中指出，MEF实际上是个组合框架（composition framework），而且定位客户是“大的应用”，两者合一，即可理解MEF的本质。
组合框架和IoC容器在表面上看很相似，都是以自动化的方式管理应用的依赖性，但其区别则在于细节上。IoC容器很久以前就不仅仅是管理依赖性了，它们还负责对象的生命周期，对象代理，面向aspect，事件聚合，事务管理等等东西。但组合框架则着重于单一个目的：依赖管理。听上去组合框架好像所做极有限，但其实不是这样。光从依赖管理来说，IoC容器往往是静态的，不透明的，而MEF则使得依赖管理变成一个动态的，透明的过程。
MEF的第二个方面，其定位是“大的应用”，极其大的应用，其中第一个客户大概就是Visual Studio本身。MEF提供的这些功能，
-不用装载程序集即可查询元数据
-可以静态地核实所有组件的依赖图和拒绝那些会造成系统处于不合法状态的组件
-契约适配器
-提供一套发现机制，用于定位和装载扩展
-允许附件元数据的标记设置，用于辅助查询和过滤
都是围绕着依赖管理这个主题的，但也大概来自Visual Studio是第一个客户的需求。因为Visual Studio涉及的组件成千上万，需要这样的东西，MEF是设计来处理这样的场景的。
Sidar Ok用了一个具体的例子来说明MEF并不是IoC容器，参考
What is this Managed Extensibility Framework thing all about ?
http://www.sidarok.com/web/blog/content/2008/09/26/what-is-this-managed-extensibility-framework-thing-all-about.html
另一件需要指出的事情是，MEF将是.Net 4.0的一部分，所以MEF将为.NET框架本身所用。
【参考】
1. Oren Eini的《The Managed Extensibility Framework》
http://ayende.com/Blog/archive/2008/09/25/the-managed-extensibility-framework.aspx
2. Glenn Block的《What is the Managed Extensibility Framework?》
http://codebetter.com/blogs/glenn.block/archive/2008/09/25/what-is-the-managed-extensibility-framework.aspx
3. Krzysztof Cwalina的《Managed Extensibility Framework》
http://blogs.msdn.com/kcwalina/archive/2008/04/25/MEF.aspx
想来很多.NET开发人员大概都读过《应用体系结构：设计应用和服务（Building Distributed Applications -- Application Architecture for .NET: Designing Applications and Services）》。自2002年以来，该文一直是开发N层.NET应用的必读经典。六年过去了，.NET版本都发展到了3.5，微软模式和实践团队终于要更新《应用架构指引》了。
据J.D. Meier，该指引的初稿已经在CodePlex上推出
patterns & practices: App Arch Guide project
http://www.codeplex.com/AppArch
在大的方面，该指引将涵盖
- 应用类型
- 架构风格
- 模式
- 逻辑层，物理层以及组件
- 架构级热点（Hot Spots）
- 表现层
- 业务层
- 数据访问层
- 服务层
- 服务设计
- 质量属性
- 趋向
- 安全工程
- 性能工程
- 基线架构（Baseline Architectures）
- 部署模式
小的方面则会讨论
- 选择表现层技术
- 选择数据访问技术
- 选择工作流技术
- 比较inline QL和存储过程
- 比较MVC模式和 MVP模式
- 比较领域模型驱动和结构驱动设计
其组织框架（App Arch Meta Frame）可参考下图
场景（Scenarios）提供了评估架构的背景和上下文， 质量属性（Quality Attributes）是指种种非功能性需求（可靠性，安全要求，性能，灵活性，可维护性等等），需求和约束（Requirements / Constraints ）是指种种影响架构的用户，业务以及技术上的规则。
应用类型包括web应用，富客户端，移动式等等。架构风格则包括N层，客户-服务器，SOA等等。架构帧（Architecture Frame）则包括了种种你需要做很多决定/ 选择的架构上的热点。
他们将关键的问题领域场景分成了几个帧（Frame），包括
1. 表现层场景帧（Presentation Layer Scenarios Frame） ，其中的热点包括
- 缓存
- 组合（Composition）
- 异常管理
- 输入
- 布局
- 导航
- 表现层实体
- UI 组件
- UI 过程组件
- 验证
2. 业务层场景帧（Business Layer Scenarios Frame），其中的热点包括
- 认证
- 授权
- 业务组件
- 业务实体
- 缓存
- 并发性和事务
- 数据访问
- 异常管理
- 日志记录
- 服务接口
- 验证
- 工作流
3. 数据访问层场景帧（Data Access Layer Scenarios Frame），其中的热点包括
- 概论
- BLOB
- 批处理
- 连接
- 数据格式
- 异常管理
- 安全考虑
- 存储过程
- SQL 命令
- 验证
- XML
4. 服务层场景帧（Services Layer Scenarios Frame），其中的热点包括
- 概论
- 认证
- 授权
- 通讯
- 异常管理
- 消息通道
- 消息之构建
- 消息端点（Endpoint）
- 消息保护
- 消息路由
- 消息转换
- 消息交换模式Message Exchange Patterns
- REST
- SOAP
- 验证
J.D. Meier的博客上还有很多相关讨论，推荐订阅
J.D. Meier's Blog
http://blogs.msdn.com/jmeier/default.aspx
今天从Oren Eini的博客上看到一个很幽默的录像，说实话，都有点心酸的感觉，估计几乎每个开发人员都会有同样的感觉
http://blip.tv/scripts/flash/showplayer.swf?file=http://blip.tv/rss/flash/1067270
请各位老板，开发主管，项目经理，今天一定要去拥抱一下你的开发人员！
[附其中一些文字的粗浅翻译]
Developers everywhere are in terrible pain.
不论何地，开发人员都是痛苦无比。
I am in pain.
我很痛苦。
We're 4 months into a 5 month schedule and I just received the final requirements yesterday (and they've changed again!)
5个月的日程，开发已经进行了4个月，我昨天才收到最后的需求，而今天，这些最后的需求又变了！
I spend half my days in meetings about how to get more work done (instead of working)
我一半的时间都陷于讨论如何完成更多的工作的会议中，而不是做工作
My boss read in a magazine that developers using "_____" programming language are twice as productive. So he bought us a copy and cut our schedule in half.
我们老板在一本杂志上读到使用某种编程语言的开发人员的效率高2倍之多，所以他给我们买了该语言，然后将我们的日程切掉一半
Every day my boss changes his mind about what we're building
对我们该开发什么，我们老板的主意每天一变
（父亲）People keep asking me to fix their e-mail, so I have no time to code
大家不停地叫我修补他们的电邮，所以我根本没时间编程
（儿子）My daddy has no more time for me
我爸都没时间陪我
Some consultants told my boss they could build our next version in half the time, for half the money. He believed them, but now they've spent all their budget, used all their time and ...are still only half finished. Now they're gone and their code is a disaster. We have to fix it and finish what they started
某些咨询师告诉我老板，他们只要一半的时间，一半的经费就可开发我们下一个版本。他信了他们，但现在，他们花完了预算，用光了时间，还只完成了一半。现在，他们走了，而且他们的代码糟糕无比，我们没有办法，只能来完成他们尚未开发完的东西
Hug a developer today.
今天，请去拥抱个开发人员
（小孩）I just finished an intensive 6 week visual basic course
我刚完成一个6星期的visual basic速成班
