解析Caliburn.Micro（一）

本文主要是介绍解析Caliburn.Micro（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

简介

　　受朋友所邀，准备使用Caliburn框架设计项目，这两天研究了一下这个开源框架，分享一下。

　　Caliburn是Rob Eisenberg在2009年提出的一个开源框架，可以应用于WPF，Silverlight，WP7等，框架基于MVVM模式，像它的名字一样，是企业级应用的一把利器。

　　之前就听说过这个项目，下载过源码简单看了看，代码注释很用心，文档说明也很详尽。不过似乎有些想法太大，10多个工程，数万行代码，钦佩之余没有看得下去。

　　显然作者也听取到了使用者的反馈，推出了Caliburn.Micro项目，Micro顾名思义，是Caliburn项目的精简版。重构了Caliburn的代码，精简掉了一些不常用的功能，按作者的话来说：

My vision was to take 90% of Caliburn’s features and squash them into 10% of the code.

　　非常给力的一句话，下面深入Caliburn.Micro，看看它的究竟。

亮点

　　在细谈Caliburn.Micro（简称为CM）之前，先来看看它的亮点。

　　基于WPF的框架有很多，Prism，WAF等，每个框架都有自己侧重点，像Prism侧重于模块间的组合，WAF侧重于分层设计。通观CM的设计，它的一些想法如下：

1. ActionMessage，结合了Blend中的TriggerAction，可以把UI控件中的事件绑定到后台方法，类似于CallMethodAction。CM对ActionMessage进行了很多扩展，包括可以传入多个参数，参数支持绑定，可以通过CanExecute作执行前判断并设置控件的Enable等。
2. Conventions，协定，这个词听上去有点虚，其实就是智能匹配的意思。CM制定了一系列匹配的规则，比如说View和ViewModel之间的匹配，绑定时传入控件名可以找到控件，传入方法名可以绑定到方法等等。
3. Screen和Conductor，作为一个Presentation的框架，各个UI部件（Widget或者叫Pad）的管理是必不可少的。Screen就是用来表示UI部件的，它定义了一些列UI部件的生命期事件，比如Activated，DeActivated等。Conductor是用来管理Screen的，类似于传统的Controller，不同的Screen可以用一个Conductor来管理，Conductor也使用了策略模式允许更改对Screen的处理。
4. Coroutines，协同程序，定义了一组程序的执行，简化了异步编程。比如说在网络中下载图片并显示，通常来说需要显示BusyIndicator，后台线程去网络读取图片，读取成功后Invoke到UI线程，取消BusyIndicator，显示图片。CM提供了一个IResult接口，大大的简化了异步编程，结合ActionMessage，为AOP的扩展提供了可能。
5. 配置性和扩展性，CM移除掉了原Caliburn的一些IOC实现，作为一个通用框架，最常用办法就是使用工厂模式结合配置文件提供可配置性，使用IOC来解耦组件间的依赖。CM默认是使用MEF来做IOC扩展的，你可以自定义Bootstrapper来使用你喜欢的IOC容器，如Unity等。
6. 设计时支持（Design-time support），CM中的ActionMessage是继承自Blend中的TriggerAction的，也就是说可以在Blend编辑ActionMessage，大大方便了使用。

评价

　　CM符合我对于框架设计的期望，精简，特点鲜明，思路清晰，不过度设计，有很好的扩展性和可测试性。指望一个框架做所有事情是不现实的，用牛刀来杀鸡可能杀的爽快，不过学习的时间成本和后期维护成本都很高，目前对CM很有好感，打算下个项目基于CM搞一搞，如果朋友们有更好的经验和建议也希望多多交流。

 

这篇关于解析Caliburn.Micro（一）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---