客户端是选择Java Swing还是C# Winform

客户端是选择Java Swing还是C# Winform？

在某大型项目中，客户要求不能用浏览器作为客户端（即不能用B/S模式），而要采用桌面客户端的方式（服务端用SSH，客户端通过Web Service访问服务端应用，并且还要求能在客户端与服务端网络中断的情况下离线进行部分业务操作，例如查询）。这可给我们项目组提出了一个大问题：客户端应用开发的技术选型。

公司有些员工强烈建议用Java Swing，认为有一些框架可以利用，例如Spring RichClient(Swing)，大家都对Spring比较熟悉，有亲近感；甚至可以考虑使用 Eclipse RCP(SWT)，因为有Eclipse在前面作为成功标杆。并且公司开发人员绝大多是Java程序员，可以随时抽调精兵强将加入任务繁重的客户端开发中，解决技术难题，甚至突击编写普通业务功能。而C#人员要重新招聘，增加了很多不确定因素。

但是采用Swing，缺点是界面比较难看，控件少得可怜，对客户端资源的控制能力差，开发难度肯定高，并且公司内部也没有积累（Java程序员都是做B/S应用的），并且在人力资源市场上，Swing方面但凡有点水平的开发人员工资都高得吓人(在51Job上查了一下)；但好处就是应用服务端与客户端都是用的Java，两边的人手可以灵活配置（当然前题是开发人员对于SSH和Swing都要能上手，一是需要一段时间学习，二是人家技能多了，肯定会要求加工资待遇的）。

并且Spring RichClient已经很久没有更新了，最新的版本是1.10，还是2009年6月发布的，在开发技术日新月益的今天，这种更新速度很叫人担心呀！难不成Spring组织已经放弃了这个子项目？！

另又看了一下Eclipse RCP，最近的更新是2009年8月的，也是叫人心里没有底呀！

而采用C# Winform，界面好看多了，界面控件也很丰富(MS自己的，第三方的都有很多)，并且RAD开发平台是MS的绝对强项，客户端运行速度也不错，安装升级很方便，人力资源市场上应用有不少储备。但要在项目组是加入C#开发人员，对于合理组织人力资源有些不利。并且与服务端人员交流也肯定会存在问题。好在C#是Java之子，双方有太多相似的地方，交流起来难度应当没有想像得那样堪比楚河汉界。

关于运行环境方面的问题，下载一个Jre，大约15M；而下载一个.net Framework大约40M。看上去.net的运行环境比Java大得多，但是要注意，从XP Sp3以后所有windows操作系统已经在安装时集成了.net运行环境，也就是说，绝大部分用户是不用下载.net运行环境并安装的。

另外就是开发模式。在Java　B/S应用开发中，一般是一个程序员从数据库、SSH到ExtJs全程贯通。好处是效率高，坏处是人员分工不明确，接口定义很随意。

在大型应用开发中，服务端与客户端的开发人员还是要分组比较好。服务端应当定义良好的接口，并且使用完备的测试用例保证其正确性与可用性。而客户端开发人员则着重于用户界面的处理，然后根据服务端的接口文档调用即可。

其实将服务端与客户端完全隔离开来也有其不利因素，就是人员交流成本会有相当程度的提高，服务端要为客户端定义明晰的接口方法，提供完备的接口文档，以方便客户端理解与调用，并且还要为自己的服务端写测试用例，以确保接口功能实现正确性。

但其有利因素也让人心动，就是提高了应用系统的模块化程度，逼迫设计人员精心划分模块、仔细设计接口，不象以前服务端（SSH）与客户端(ExtJs)都是一个人在做开发，很多本应当明确定义的接口，开发人员都只是按自己的意愿随意设计修改。同时，集成第三方应用时，也不用专门费时费力再开发接口，只是将已经设计实现的接口包装一下，加上权限等对第三方的限制条件即可。

我们公司作为一家以客户为导向的应用系统服务型公司，在技术上不应做太多、太深入研究，跟着主流和客户的要求走就没有错！现在服务端的主流是什么？Java(SSH)。客户要求客户端不用浏览器，要做成桌面应用，那现在桌面应用开发的主流是什么？C#WinForm(或者WPF)。桌面应用要求跨平台吗？不用。现在对外发布远程应用接口的主流是什么？Web Service，那我们服务端与客户端的通讯方式就只有采用Web Service。

看上去采用Java的长处很明显，短处也很明显，带来的风险也大。而C#一切都显得很中庸，但相应的风险也小。我们还是取中庸之道吧！Java Server+C# Client。

另外，根据同事提出的不同意见，有以下几点说明：

1、在网络上，开发人员公认C# Winform或者WPF的界面库肯定比Java Swing的丰富得多。可能是概率的问题，我们运气不好，正好没有找到，或者没有合适的人来进行这方面的工作；如果有可能，我们可以在下一步用WPF库（反正.net运行环境已经安装了）；

2、在客户端，主要的工作是用户界面处理，这方面不会用到复杂的C#语法与语言特性，主要是对控件的使用（界面事件的响应代码占到60%以上），在这方面编程中，C#与Java在语法上的差别不是太明显，要求人员通吃两边的难度确实不大，对Java开发人员来说，主要是学习熟练使用VS界面及界面控件；

3、关于Web Service的问题，我觉得采用Json是一种选项，实际上.net中也有原生Json处理类。但采用文本方式传递对象产生很多摸名其妙的问题，例如我在服务端一个应用接口中加了一个字段，或者改了字段类型、长度，如果在客户端有几个功能都用到了这个接口，有的可能会正常使用，有的可能会报错，这样给客户端开发、调试及测试带了很多额外负担(困惑与不一致)。如果采用严格的对象接口，在调用时就会全部报错，实际上对开发工作更加有利。并且生成接口看似增加了工作量，实际上可以一次生成，多次使用，而Json格式可能会由各个客户端开发人员各自解析与理解，反而耽误时间，也更有可能出错（当然也可以写一个中间层，统一转换成对象接口，但增加了工作量及出错的可能性）。客户端Web Service接口的生成在VS中是很简单的，可能我们没有找到合适的方法吧？实际上客户端应当有专门的Web Service接口处理工作岗位来统一管理配置Web Service接口，生成桩代码、数据传输实体类及DLL接口库，并提交给其他开发人员直接调用即可，这也是分层开发的要求，不过我们现在没有设置这样的人员岗位而已，这也是我们组建结构合理的C#开发团队的要求之一。

4、因此，问题的根源还是在于人事。项目开始时，我们有成熟的Java框架，有熟练的开发人员，但在C#方面，没有成熟的框架，也没有开发人员，找了一两个新人就开始搭建如此重要的客户端技术框架，这完全是“事倍功半”的做法，但项目进度与人事安排的困难在那里，这也是没有办法的办法。如果一开始就能找到合格的C#的技术架构师，能带来成熟的框架（就象我们在Java服务端的），后面的问题都不会出现。

5、最后，值得高兴的是，现在客户端开发的最困难时期已经过去，不管架构好不好，我们的客户端框架已经建起来了，也已经开发了很多实际的应用功能，并且运行也算良好，这就是一个巨大的胜利。我相信，再过一段时间，客户端开发人员结构会日趋合理，框架也会稳定起来，好用起来，开发工作会越来越顺利。