基于 SailingEase WinForm Framework 开发优秀的客户端应用程序（1：概述）

本系统文章将详细阐述客户端应用程序的设计理念，实现方法。

本系列文章以  SailingEase WinForm Framework 为基础进行设计并实现，但其中的设计理念及方法，亦适用于任何类型的客户端应用程序的设计与开发。

目录：

http://www.cnblogs.com/sheng_chao/p/6084144.html

前言：

可能是接触计算机比较早，从96年左右386开始，到 Trubo C，以及后来的Foxpro、VB、Delphi，一直以来似乎都有一种客户端程序情节，喜欢写客户端程序。

在 .Net 出现以后，投入了许多时间在研究 .Net 编程上，在客户端领域早年基本以 WinForm 为主，近几年逐渐转向了 WPF。

除了日常工作中的项目开发，业余时间使用 WinForm 写过许多东西，比较成型的大概有两个

1）SailingEase WinForm Designer IDE （2007~2010 暂停开发）

    http://www.cnblogs.com/sheng_chao/p/4387249.html

高度实现的 IDE 开发环境，完整实现了 WinForm Designer，可通过可视化配置的方法，定义界面和业务逻辑，并使用 XML 进行描述。

这个项目一开始的设想，心很大，企图做一个让不懂编程的人，也能拖拖画画加上配置，来生成企业所需的管理软件。投入了大概两年多的业余时间，这期间应该是我自己开发能力和设计能力增涨最快的时期，开始做这个项目的时候，有太多的问题超出能力范围，只好到处找书看、找资料学习。在每天回家的路上看完了《设计模式》，平时的碎片时间看完了《代码大全2》，另外阅读了 SharpDevelop 的许多源代码，也有一部分的实现是参考了它的思路和代码。

2010年左右由于时间和精力有限，加上对于软件项目有了一些新的认识和想法，这个项目就暂停至今。其它几个小规模的 WinForm 项目，和本系列文章的主角：SailingEase WinForm Framework，均脱胎于此项目。

2）SailingEase .NET Resources Tool

http://www.cnblogs.com/sheng_chao/p/5958846.html

　　一款辅助多国语言软件开发的实用工具，目的在于通过生成接口来约束不同语言资源的实现，使开发人员可以基于接口调用资源。 此外，提供方便开发人员使用的各种实用功能，如多项目并行编辑，资源导入，Excel 导入、导出等。

　　这个项目源自于上面的 IDE 项目，由于做 IDE 时心太大，希望能够支持多国语言，但是慢慢发现从工程角度来说，这是一件非常麻烦，容易不可控的事情。就花了结时间，想了一个办法，用接口来约束不同的资源。

最后祭出本系列文章的主角：SailingEase WinForm Framework。

其实这是从 IDE 项目中提取出来的一个纯开发框架，它没有用户管理、权限管理之类的现成功能，而是提供纯开发角度的开发框架，概括来说提供了以下几方面的功能：

a.宿主程序（壳）与功能模块（插件）的加载、调度、通信等实现；

b.不同插件之间在完全接耦合的基础上，同步/异步调用、状态响应等机制的实现；

c.插件之间在代码层面完全没有互相引用关系，可以实现在缺少任意插件的情况下启动应用，即使他们在UI层有交集；

d.支持模块间的依存关系定义；

d.事件聚合器，用于在完全解耦的条件下，发布及订阅事件；

d.宿主程序提供了统一的主菜单及右键菜单的注册/吊销/状态控制机制；

e.宿主程序提供了统一的窗口调度/加载/销毁功能；

f.宿主程序提供了统一的日志记录、异常捕获，Web页面互操作等功能；

g.基于 GDI+ 自行实现的控件包，提供了高度的可扩展性；

h.基于zip格式的文件包管理器（基于zip的自定义文件格式，读取或写入指定的流）；

i.对http、xml、磁盘io、反射、加解密等操作的增强与封装；

j.其它……

第一章节：客户端软件的架构设计概述

本章节将概述基于 SailingEase Winform Framework 框架的客户端应用程序的架构设计。

时常有朋友或者客户会问：“你这个软件是不是三层架构设计”。

实际上客户端软件的架构并不是这么划分设计的，也远远比所谓的三层架构要复杂的多，与 Web 程序在不同的页面间无状态跳转不同，客户端程序更加成一个整体，单页面 Web 应用有一些方面与之类似，不过亦有许多不同。

我们通过一个简单的设计图初步了解基于 SailingEase Winform Framework 的客户端程序架构：

 SailingEase WinForm Framework 的核心，就是模块化。

基于 SailingEase WinForm Framework 框架的应用程序由运行时动态加载的松散耦合模块组成，模块包含代表系统不同功能的可视和非可视组件，可视组件（视图）被组合在一个外壳中（主窗口）。

宿主程序提供各种基础服务，并将这些模块级组件结合在一起；模块也可以提供与应用程序的特定功能相关的其他服务。

SailingEase Winform Framework 是“复合视图”设计模式的实现，此模式支持包含子项的视图递归结构。这些子项本身也是视图，这些视图通过某种机制组合起来（在运行时动态组合而非设计时静态组合）。

模块永远不会相互直接引用，也不会直接引用宿主。它们会利用服务、事件聚合等机制在彼此之间以及宿主之间进行通信，并响应用户操作。

使用模块来组成系统有很多好处。模块可聚合来自同一应用程序中不同后端系统的数据。此外，系统可随着时间的推移更加方便地发展演变。在系统需求发生变化而需要向系统中添加新模块时，与非模块化系统相比，模块化系统面临的冲突要少很多。而且还可以对现有模块进行独立性更强的改进，从而改善可测试性。

模块可由不同的团队开发、测试和维护。在小团队开发维护模块时，也不必加载编译整个应用程序解决方案，只需建立一个包含宿主和指定模块的精简解决方案即可。

在 SailingEase Winform Framework 中，可定义不同模块间的动态依存关系，有时一个完整的业务操作需要不同模块间协作完成，而其中有些环节不是必须的，此时我们可在缺失部分模块的情况下，正常执行完整个业务流程：

主动模式：

主动模式使用建造者模式进行实现，由业务或操作的发起模块主动控制流程，由其自身判断需要响应的模块和模块是否存在。

　　　

被动模式：

被动模式使用事件聚合器进行实现，业务或操作的发起模块完成自身操作后，向事件聚合器发送通知，在事件聚合器中注册过的模块会收到相应的通知和数据，从而响应业务操作，响应事件聚合器的不同模块可使用多线程技术并发处理。

在被动模式中，事件的发布模块，完全不关心有哪些模块会响应事件，也不关心事件的响应结果。对于响应事件的模块来说，它们也不关心事件是由谁发布的，只需处理好相应的业务即可。

视图级别的动态依存：

举例来说，当我在用户信息模块中的用户列表画面中选择用户时，画面底部需要显示用户最近一笔订单，而这个订单信息区域（View），需要由订单模块提供，但是当订单模块不存在，或没有加载时，用户画面依然可以正常显示及使用，只是显示订单信息的位置，被隐藏了。

当用户模块和订单模块同时存在时：

　　选中用户列表中的用户，则在画面下方自动显示其最近订单。

显然用户模块与订单模块不仅有视图层面的融合，还有操作响应上的融合，而这些融合与调用，在 SailingEase Winform Framework 中是完全解耦合的，两个模块之间不存在任何互相引用关系。

当订单模块不存在或没有加载时，用户模块中的画面将自动调整，UI操作不会有任何影响：

模块化只是基础，除了模块化之外，作为宿主程序，通常会提供一系列的基本功能实现。

其中特别重要的有几点：主菜单/右键菜单/工具栏的融合与调度，窗口调度器、线程调度器、服务容器、事件聚合等等，我将在后续的文章中详细阐述。

一个典型的基于 SailingEase Winform Framework 的应用程序架构

以 SailingEase WinForm Designer IDE 为例：

　　

运行时效果：

在下一章节中，我将对客户端应用程序的架构作更进一步的阐述，并详细说明基于 SailingEase Winform Framework 的模块化开发如何实现。

欢迎加我QQ交流探讨，共同学习：279060597，另外我在南京，有南京的朋友吗？