Silverlight 之轻

第二届Silverlight Firestarter 发布会在美国召开，微软企业副总裁 Scott Guthrie 发布了Silverlight 5 的一系列新特性，并宣布Silverlight 5 将注重丰富的媒体体验与企业应用开发两大方面的改进。其中针对媒体方面的改进包括GPU硬解码、H.264等5项功能，而针对企业应用方面的改进包括64位操作系统支持、IE 9硬件加速、向量打印、文本清晰度、调用非托管代码等30多项功能，可以看出Silverlight已经逐渐将其未来重心转向企业级应用方面(一直以来，笔者都认为Silverlight的强项应该是企业应用)。

Silverlight作为微软“三屏一云”战略中展现层的重要技术，越来越引起企业开发者的注意。新浪财经、腾讯、淘宝、口碑网等互联网企业已经尝试使用Silverlight开发交互性较强的商业应用，而一贯谨慎保守的大型金融公司陆续开始使用Silverlight来提高企业应用的用户体验，比如中国人寿(网上服务应用)、中国人保(商务智能应用)已经有相关应用，而像花旗银行、工商银行这样的大型银行也在尝试使用Silverlight来实现未来网上银行一些功能。

为什么Silverlight在推出短短三年左右时间内就能触动企业开发者呢?原因很简单，Silverlight具有良好的后台语言框架支持，这就是基于.Net高级语言的精简运行环境。具体而言原因有三：

1. Silverlight之轻，即较之WPF、Java Swing、Delphi等C\S架构有更加轻量的运行环境与零维护的特点：使用轻量的CLR Core运行时环境，不依赖于客户端环境(无须安装体积庞大的.Net Framework，这一点太棒了)。

2. Silverlight之重，即较之Html+JavaScript等B/S架构有更优越的客户端弹性：使用C#高级语言代替JavaScript来实现强大的客户端计算能力、支持多线程，继承了WPF丰富的样式、控件、特效与动画，更可控的浏览器适应性，更安全的沙箱模式，客户端嵌入式数据库等。

3. Silverlight之美，即较之传统应用有更友好的交互性，更酷的效果。支持完全面向用户体验的开发过程，其快速原型工具使需求与交付物更为明确，用户体验驱动开发，设计与编码分离。

在本文中，笔者要着重强调的是“Silverlight之轻!”， Silverlight是企业应用展现层的轻量级解决方案，从本文开始，笔者将采用连载的方式与大家一起探讨Silverlight在企业级应用解决方案与特性。

现在越来越多的企业已经开始考虑将原有“竖井状”的C/S与B/S架构通过SOA等理念进行重构与集成，譬如建立以客户、产品、合同为中心的主数据管理平台(MDM)，采用数据即服务的方式对逻辑层提供服务，使用企业服务总线(ESB)对这些服务进行消息路由、转换、监控及生命期管理，通过业务流程管理平台(BPM)混编服务实现业务流程自动化，通过业务规则管理平台(BRM)实现对业务逻辑自动化，最后这些应用层服务形成了企业应用的服务器端处理逻辑。而展现层就是企业应用中实现人机交互的最后一步，即信息的输入与展现。现在的企业应用解决方案中基于窗体的C/S与基于浏览器的B/S架构几乎构成了企业应用的全部，但两者都有其优缺点，C/S架构在客户端的处理能力与交互性较强，但维护性极差;相反，B/S架构在客户端的维护性极高，但对信息的处理能力、交互性、跨浏览器一致性方面都有不足。正是如此，相对C/S架构更为轻型的Silverlight技术就成为了未来高度集成化的企业应用中理想的展现层的候选方案。传统的C/S架构，无论是VC++、Delphi、Java的Swing、还是.Net的WinForm、WPF都需要安装体积笨重的运行时环境，即使客户端程序永远不会使用运行环境中的特殊组件，但使用者也只能被动接受这些组件占用计算机资源。而Silverlight有着更为轻便的运行式环境(Silverlight3的运行时环境4.3M，Silverlight4为6M)，在如此小的运行环境下面有着B/S无法比拟的高级语言支持，也就是说Silverlight具有一颗.Net的心脏—CoreCLR。

CoreCLR简单来说就是CLR for Silverlight，是专门为Silverlight量身打造的轻型CLR，用来执行Silverlight代码。Silverlight基于C#高级语言，使用同样的托管机制与MSIL中间语言，CoreCLR自备编译环境、内存管理器，不依赖于外部环境。打造这个轻型“心脏”的过程并不容易，对于轻型的RIA框架来说Silverlight运行时环境要考虑两大问题：大小与兼容性。

大小就是运行时环境的大小，从用户的角度来看，下载必须非常小。这就要求将功能集减至最少，目前 Silverlight4运行时环境大小为6M，CoreCLR中的DLL文件在CLR和WPF的类库中几乎都能找到，只不过大大裁剪了尺寸。这其中就包括对基类库(BCL)的消减，.Net BCL中的很多功能在 Web 客户端上都没有任何意义，例如：由于 Silverlight 不支持 CAS，因此大部分 System.Security 都不是必要的，System.Console 等许多桌面类在 Web 中也没有任何意义。因此，CoreCLR删减了大量服务器端类库(如ADO.NET)，去除非泛型集合类(如ArrayList，完全可以通过泛型集合类代替)，同时将复杂的桌面类也一并去除(如PLINQ和一些动态类)，但保留了.NET Compact Framework 和 Silverlight 间的兼容性。

对于兼容性而言，从编程人员的角度来看，针对 CLR 的编码应该始终相同。因此，Silverlight堆栈底部的各个组件使用了与桌面CLR相同的代码，执行引擎和虚拟机都必须相同，这部件包括类型系统、元数据、垃圾回收器 (GC)、JIT 编译器、线程池以及运行时引擎的其他核心部件。但为了适应 Web 应用程序，CoreCLR进行了一些更改，如富 Internet 应用程序通常简单且运行时间短，JIT 编译器主要侧重于减少启动时间，而非执行更复杂的优化操作，同样，服务器垃圾回收模式可以对使用相似分配模式的多个工作线程进行优化，而对 Web 托管应用程序则行不通，因此，Silverlight 只包含针对交互式应用程序进行优化的标准工作站 GC。

现在的.NET Framework里有一万个类，十万个方法，但CoreCLR中减少到了46个命名空间下不超过一千个类。

C#之父(同时也是Turbo Pascal与Delphi之父)Anders Hejlsberg认为未来编程语言的发展趋势及未来方向应该朝着框架与工具发展。笔者认为未来的语言发展方向不是朝着大而全的运行时框架方向发展，而是朝着“轻框架、重工具组件”的方向发展。当我们使用Visual Studio开发应用程序时，我们首先选择的是“语言”，然后是“运行时框架”，再引入我们需要的“工具组件”。而精干的“运行时框架”与丰富的可选“工具组件”将为企业应用提供更大的弹性、减轻程序大小、优化响应性能。

事实上，目前很多金融企业的核心应用已经在朝着“去客户化”、“去产品化”的小核心方向发展，“小核心”+“大外围”使企业内部核心具有更加持久的生命力、更加灵活的扩展性和更快的反应能力。而企业应用展现层也越来越青睐于使用小而灵活的运行时环境，开发者完全可以根据实际需求挑选合适的工具组件，提供更富弹性的展现层应用。Silverlight的未来应该更加关注适用性，而不应该过度考虑基本功能的强大，否则将发展成为另一个WPF，而失去自己的方向。Silverlight4将Silverlight3的身躯加大了1.7M，加入了一些诸如集合接口ISet、延迟初始化类Lazy、元组对象工厂类Tuple等复杂类型，加重了Silverlight内核。因此，在Silverlight5的Wish List中，笔者强烈要求Silverlight5关注解决跨设备的问题，而不要过度考虑加重基础类库的强大功能，加重Silverlight的包袱，使原本轻便的Silverlight CoreCLR变得更加臃肿，无法起飞。