这些年大家都在说：Swing学起来费劲，用的也不多，见到的应用也不多，能做大型应用么？最近还有朋友看了几刀之后就说，哎呀快去学Swing吧，做东西好漂亮！其实这不仅让人哭笑不得：几年前大家还是一边倒的打骂Swing太丑，都说Flex啥的漂亮，突然有人夸起Swing做东西漂亮来了，还真很不适应。还有人说，Swing快不行了，Sun也不行了，Oracle也不行了....其实在他们眼里，也许Java也不行了，软件开发也不行了....那到底Swing做大应用能行吗？通过自己参与的项目经验来说：这个真的行！
这几年一直在做Swing的开发，有幸参与了公司一个大型的ERP项目。这个ERP项目规模很大，我的NetBeans工程里就有150多万行代码，还不包括其他小组的分支模块。前端除了桌面客户端外，还有浏览器和手机终端，不过最重要的还是Swing版的桌面客户端。这个Swing版的ERP客户端开发了已经7年多了，JDK从1.3一直升级到现在的1.6，IDE也从IDEA、JBuilder到Eclipse、NetBeans。不过核心框架一直没有什么大变化，应用也比较成熟。
这是一个大型的ERP系统，典型的C/S结构，也混合了一些B/S结构和手机终端的模块，不过主要内容还是在庞大的后端和Swing的前端。后端主要用J2EE架构搭建，通过JBoss应用服务器和MySQL数据库，Hibernate做O/R，自己封装DAO层以及Business层控制业务逻辑，再用Ejb进行业务API封装。最后，通过一个Facade层的EJB（后来改造成Servlet）对外提供统一的访问接口。这个接口也是整个后台唯一的访问接口，这个“一夫当关、万夫莫开”的入口处，再插入登录和会话管理、安全控制、日志记录、请求分发等机制，干净简洁。通讯协议，以前通过EJB和IIOP的协议开放API提供远程调用，后来发现EJB的通讯非常异常繁琐和“重”，各种控制比较复杂，效率也不好。后期版本改造为用一个Servlet封装对外提供接口，协议也变成了HTTP。这样，后台通过一个80端口，以类似WEB的方式统一提供前端的API访问。对很多人来讲，这个方式可能有点奇怪：Swing的胖客户端，还用HTTP的WEB协议来访问后台。嘿嘿，其实这一招不错哦，仔细琢磨一下会体会到其妙处。
前台是一个完整的Swing程序，也是通过层层封装，提供了一层与服务器一一对应的API访问层，最后通过一个统一的代理类，对后台进行访问。通过HTTP如何传输Java对象呢？我们没有使用Web Services之类的技术，而是直接把要调用的方法以及参数等信息序列化，以HTTP方式提交后台，后台通过模块分发、反射的方式执行函数后， 把结果数据进行序列化，再经过压缩，通过HTTP返回客户端。客户端将数据解压、反序列化，将对象再返回API的调用者（如各个界面、按钮等）。这个结构非常高效、可靠。甚至包括函数的异常等，都可以通过序列化进行传递。
通过HTTP的方式，服务器不再需要防火墙开放更多端口，和web应用一样，一个80就行了。另外，和web传递html等信息不同，这种结构下，中间传递的就是压缩过的Java对象序列化后的字节流，其效率是很高的。客户端是胖结构，自然可以处理更多的数据处理和呈现，比浏览器也有优势，很合适ERP这种企业应用。轻量、高效的结构也提供了很好的业务支撑能力：一台普通的台式机可以提供100个ERP用户同时在线、比较流畅的使用。这对于没有专门预算购买专业服务器和建设机房的企业来说，是非常给力的。
至于Swing的客户端是否能做的好看，这个就要看是否用心了。只要用心，什么UI技术其实都无所谓，都可以做出漂亮的应用。这里提供两张贴图，是否好看还是仁者见仁、智者见智了。
通过这两年的Swing开发，也总结了一点经验，和大家分享：
- Swing入门较高，有一定的学习曲线。企业在选择是否采用Swing技术之前，一定要分析是否合适自己的团队。如果没有一个半个Swing比较好的骨干带领，Swing的复杂度很容易让整个项目代码失控，最后变成一个“好大好大好大的垃圾堆”。
- 代码要尽量一层一层的搭框架，不断的重构、优化、复用，不可每个人按照自己喜好自搞一套，否则很容易失控；代码和风格甚至开发工具都要尽量一致，避免维护的麻烦。
- 找一个好的美工。美工设计很重要，他（她）会从不同于程序员的眼光来创建和设计UI，我们一定要尊重美工的设计思路，不要轻易指手画脚、大放厥词。术业有专攻，要知道，在美术方面咱们程序员大多是小学生水平。一旦设计风格确定，就严格按照统一的风格进行开发，每一个对话框、每个按钮、每个图标。让一个ERP中成千上万的对话框都“如出一辙”确实不易，不过应当是目标。
- 永远从“用户”角度设计UI。开发UI也是设计的过程，美工没可能把一个ERP系统中成千上万的对话框都设计出来，程序员这时候就是半个美工、半个用户。让大脑里时刻存在一个“用户”并时刻敲打自己：这个界面好用吗？这个报表能看懂吗？这个按钮位置合适么？做软件就像盖大楼，地基结实固然重要，窗户密封性就不重要了吗，外墙涂料就不重要了吗？要做百年屹立的优质工程，就得处处关注细节。别忘了房子是用来住的，软件是用来用的。
补充：上面有两个下载：一个是exe的setup安装，一个是直接解压即可运行的zip包。后台其实也可以跑在linux等上面，启动脚本需要自己写一下了。
刚发布的免费ERP系统（www.2bizbox.com）后，大家反响很热烈，短短3天就被下载了2万多次，服务器一度宕机，呵呵。大家讨论也比较热烈，纷纷提出不少问题和技术探讨，感觉非常有意义。这次和大家分享一下关于这个免费ERP的架构设计。之前先回答一下大家比较关心的一些问题：
- 网站只提供了windows的exe安装版，大家询问是否有适合linux跑的版本：这个可以有，不过还需要一点时间来发布，几周后就会有下载，请大家耐心等待并及时关注。目前，官网上已经提供了exe和zip，不过都是针对windows平台的。
- 下载后一些朋友无法解压和运行，尤其使用迅雷等工具的朋友。这个原因还不知道，可能和多线程下载以及网络有关，可以在下一次，或尽量不使用工具下载。由于服务器在国外，下载速度肯定不会特别好。不过一些热心网友已经提供了国内的下载链接，官网较慢的可以试试这里：E备是链接地址，输入验证码即可下载。我家2M带宽，用chrome 自带的下载工具下载，大约用了8分钟完成下载。另外还有JavaSwingChina、天极网下载、华军软件园、绿色软件联盟、旋风下载、中关村在线、豆豆软件站、。。。似乎一夜之间遍地都是了，呵呵
- 还有朋友关心公司是国内的还是国外的：公司是美国的，不过我们上海这个小团队负责一部分开发工作。在国内也有不少客户，例如中石油、襄钻股份、江汉三机、四机赛瓦等，我们负责本地客户服务。
- 有朋友询问是否开源：目前是软件完全免费，源代码开放的事情还没有消息。不过个人判断完全有开源的可能性，呵呵，这要看美国人是怎么想的了。
- 很多朋友关心团队协调，高手低手如何共同工作，一个人搭框架，另外人不满意怎么办等等。我想这个并不是一个软件团队的特有问题。要说是问题的话，是咱们中国人特有的一种毛病还差不多。“不服气”从来是咱们的特点，问题不是高手太少，而是“大明白”、“专家”、“牛人”太多了。我曾经去一个制造厂做实施，接我们的司机谈起公司的管理来，那真是口若悬河、吐沫横飞、头头是道，上至老总下至看大门的，都被分析的“体无完肤”，好像马上换他去当老总一切问题立马解决似地。所以我认为这根本就不是一个问题。想想“奥迪R8”和“宝马7”这样的工业精品都有一个总设计师，你是在问，BMW的一个刚进去工作的学生如果认为宝马7系的总设计师设计有问题该怎么办？
还是来说说架构。先看这个图就都明白了。
提到架构，我们用到的第三方的框架不是很多，总的原则就是尽量简单、稳固。这样，就会高效、好维护。这远比一些乌七八糟的所谓新思想新技术更加重要，毕竟我们的软件要维护几十年的（实际上已经从DOS到现在开发了20年了）。后台主要是JBoss和Hibernate，其他大部分部分都是自己封装。前台则基于Swing以及自己封装的各种组件。中间通讯也没有采用第三方的框架，而是自己封装，主要采用HTTP协议，对交换的VO（包括VO集合）对象（如参数、返回值、Exception等）进行标准的Java二进制序列化、zip压缩、传输。调用的方法通过一个统一的invoke进行传递，被调用的模块、方法名、参数等，都被封装在一个POJO中传给后台。后台Façade层解压后，根据具体模块，通过反射的方法，调用Local的各个模块EJB，执行具体函数。每个函数先在Biz业务层进行业务逻辑分解处理，例如，如果要添加一个零件，要分解很多具体动作，先检查零件号是否重复，再检查零件号是否格式合法，数据是否完备，创建零件库存初始信息、创建物料添加日志、通知相关人员…等等。分解后，形成具体的DAO操作，然后交给DAO进行调用相应的底层API完成。无数的DAO对各个业务数据进行各种数据级别的操作封装（增删改查等），然后通过Hibernate层进入数据库。
有朋友喜欢用Eclipse RCP来作为前台框架。坦白说，我个人对SWT一向不喜欢，也不看好，因为他本质上和AWT的路线没什么不同，只是后台老板从SUN换成了IBM。当初以“好看+效率高”的旗号，SWT曾经风靡一时，人人趋之若鹜。不过本质上说，SWT这种技术是打着“好看/速度快”幌子分裂JAVA的政治游戏，我们程序员应当看清楚。当然不是说SWT技术不好不能做企业应用，实际上我认识的一些朋友已经用SWT搭建了好大好大的应用。不过SWT毕竟不是JAVA的官方技术。如果相信JAVA的未来的话，我觉着应当相信SWING才是正道。SWING有不足，但是它会不停的发展。另外，千万别总拿“丑”和“慢”来攻击Swing，说到底还是看你会不会用，吐口水实在无意+无聊。说道RCP框架，我倒更喜欢NetBeans。不过国内大家还是把Netbeans当做IDE来用，实际上这个RCP平台相当不简单，质量很高而且国外应用很多，已经非常成熟，有空可以多看看Netbeans的Platform频道（不是IDE哦）。
HttpInvoker没有用过，不知是不是和Spring绑的比较死，看上去和我们的通讯方式完全类似。其实java序列化再传输就是几行代码的事情，如果不用Spring等框架，完全没必要用第三方的，自己封装一下就好了。看看这个代码就知道了：
代码Hessian基于WS还可以支持不同的客户端，也很不错。不过我们这种需求不大，没有使用WS以及其他客户端技术的需求，也没有采用。还是觉着简单的东西自己封装更加的灵活和容易控制。我们的思路是尽量少的引进第三方的框架。过多的异构框架导致的稳定性和灵活性的代价也是很大的。
其他一些类似MQ之类的异步框架就更比较谨慎使用。前后台调用需要实时性，肯定是同步调用为主。异步的情况不多，即使有，在基于HTTP的结构下（例如只开放80端口）也比较难实现。我们采用了JBOSS的JMS机制，实现一些后台主动发送业务消息、上传图纸等功能。当然如果后台禁止了相应端口，客户端就自动放弃JMS连接，工作在纯“主动模式”下，相当于一个“浏览器”。
对于非桌面客户端，例如手机、数据采集器、PDA等，我们在后台的Façade层上面再包装一个又一个简单的“协议适配”就行了，也就是把Java的对象简单的封装到XML或HTML，负责与这类终端通讯。这样，身后的安全啊、日志啊、业务啊等就完全复用，开发速度是很快的。对于大多手机，使用XHTML进行浏览即可；对于iPhone等则开发native的终端，对于PDA和数据采集器，由于有条形码、收料发料、盘点等复杂应用，所以用本地的环境进行创建GUI（一般都是Windows CE，可用C#进行）。这样，我们的架构可以简单快速的支持各种不同的终端接入：
有朋友担心一个Servlet提供所有API太变态，其实不必担心。没错，我们的模块API至少上万，但是这个后台的Façade Servlet其实只有不超过10个方法。最主要的一个是invoke，方法都是通过一个对象封装了模块、方法名、参数序列等来通过反射机制完成的，所以，无论后台模块API有多少，只要通过这一个唯一的业务入口出入就行了。至于前台使用不太方便的问题，可以通过前台再次封装展开来解决。
最后送Swing界面：设置会计年度
http://www.cnblogs.com/zhangchuanzheng/archive/2011/01/19/1939423.html
