客户端设计回顾

接前面几篇回顾性文章，再说说刚做完项目中客户端框架的设计，
客户端在项目初期就选择了EclipseRCP，当时给的理由是Swing太慢，
现在项目做完了，没人再说这句话了，
因为EclipseRCP更慢，尤其是表格控件，折腾了几个月，
客户端的设计不是由我主导的，只是后期我也加入修复问题，
因客户端的设计人员频繁更换，并且时间伧促，加上会EclipseRCP的开发人员又少，
最后得到的结果是不怎么理想的，而且文档更新不同步，感觉有点面目全非。
客户端整体框图如下：

1. client.libraries 包含所有第三方库(如：httpclient.jar等)以及domain,exception等实体或值对象。
2. client.common 是框架的主要实现部分，包括封装的控件，传输组件，同步，缓存，权限等等。
3. bar.main, exp.main 是各子系统的主工程，其它模块插件都部署到它的内部运行。
4. client.launcher 是一个使用Swing写的WebStart适配，负责分发整个应用到客户端，并作版本检查。
另外的，就是模块插件了，由业务组开发。
几个大问题：
1. client.libraries 不应该放domain,exception等实体或值对象，
他们应该属于各业务模块，如果强制把序列化对象全放到框架中，
在开发过程中使得libraries经常变动，而且可能冲突，
另外，这使得框架反向依赖于业务模块，
开始的原因是，Eclipse各插件之间ClassLoader隔离，经常出现类找不到，所以就全放到底层去了。
后来找到办法解决，但业务组已经基于这种方案在开发，协调比较困难，就只能用下去了。
2. bar.main和exp.main不应该存在，
不知道为什么会为每一个子系统建一个工程，让架构组来维护，有点莫名其妙，
如果再加几个子系统，难道架构组需要继续加工程？
这两个工程里就是些EclipseRCP启动事件类(如：ApplicationWorkbenchAdvisor等)，一模一样，
完全可以放到client.common工程中，让client.common作为启动工程。
而现在却是在client.common工程中放了一堆抽象层(如：AbstractApplicationWindowAdvisor)，
然后让bar.main和exp.main一对一去继承，这个隔离层没有多大意义，
如果说为了各子系统可能有不同的需求，完成可以通过特殊的模块插件实现。
3. client.common中定义的国际化组件，在模块中居然用不了，
这个国际化组件只读取了client.common自身的properties文件，
模块中就只好每个人都照抄这个国际化组件，搞得Messages类到处都是。
4. 还有类的分包，我没看出个所以然，如：登录功能就在5个包下有类，实在摸不透。
另外，小问题也有不少，冗余类也不少，到后期都是能不改就不改，稳定第一。
要整理客户端框架，工作量可不少。