愚者千虑

OO和SQL，应该携手共进

lgx522 — Thu, 03 Jul 2008 16:30:06 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/211165 发表时间: 2008年07月03日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近两年来，经常在OO和SQL这两兄弟阵营里转来转去，总想做出个“决断”，结果却是谁也舍不得，手心手背都是肉啊。

十年前学应用开发的时候，SQL是绝对的王者，一直也就用了好几年，搞定了不少事情。有时候也觉着烦，尤其是许多不相干的调用代码，罗罗嗦嗦粘贴个没完。这时候总是想，能不能轻松点啊。

这时，以Hibernate为代表的ORM流行起来了，笔者也就兴冲冲地投入到实践当中。四五年前已经可以很舒服地配合Spring的Hibernate Template写代码了，那是相当地省事啊。虽然Hibernate也不是盏省油的灯，费了不少学习和调试的时间（老实说笔者到现在也算不上精通），好在以OO方式写应用，逻辑代码清晰多了，结构化进一步提高，也算值了。这时候又在想，还能不能更轻松点啊。

而这时，RoR火了起来。笔者在一年半前一接触，立马就迷上了Active Record，以前多少烦恼似乎瞬间烟销云散了，实在是非常的爽快！这个阶段，笔者已经彻底成为OO的迷信者，言必OO，并且深信以AR为代表的DSL是企业应用的最佳解决方案。

整好这时碰到一些传统C/S转B/S的企业应用项目，笔者满以为可以轻松搞定，结果却是出人意料，竟然被这些项目当头打了一棒。由于传统企业应用是以写为主的OLTP，并混合了部分查询相当复杂的OLAP，性能要求还是比较高的，ORM很快就败下阵来。很多时候甚至逼迫笔者重拾SQL，这时候两难的境地出现了：一边是清晰的OO，一边是高效的SQL；普通CRUD是OO的强项，而复杂的查询统计则又是SQL的天赋。笔者于是无奈地在这两个阵营里转来转去，一面到各个技术站点寻求“真理”。可惜这年头，以SQL为代表的传统阵营和以OO为代表的新生阵营有些“水火不相容”的味道，正是“人也多嘴也多讲不清道理”。寻求得越多，也就疑惑得越多。自己也参与并发起过一些争论，结果愈发云山雾水。

工作生活疲累之余，信手翻翻十多年前一度热衷的儒释道经典，这才猛然间有了“不识庐山真面目，只缘身在此身中”的觉悟。答案其实已经在笔者实践的“无奈”当中。由此可见古人“兼容并包”的睿智。
正所谓OO和SQL，本是同根生，相煎何太急。与其争论谁比谁更高更强，不如共同携手解决现实问题。

在此原则下，笔者对项目中SQL不爽的部分改用OO，OO不适合的地方沿用SQL，终于达到了很好的平衡。
于是，曾经深信而后怀疑否定的的AR，携手SQL老大哥，相当痛快地解决了大部分企业应用问题。
对立并非正途，合作才是王道，这个道理在代码领域同样成立。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Spring性能小测，参其它技术

lgx522 — Wed, 04 Jun 2008 18:25:04 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/200224 发表时间: 2008年06月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

昨天参与了“有感而发：JavaEE和ROR的本质区别，以及对ROR的抱怨”（http://pig345.javaeye.com/blog/199384）博文上的口水战，对Quake Wang老兄所说的“Ruby比Java确实性能差很多，但是RoR和Struts + Spring + Hibernate做的网站性能是在同一级别的”产生了兴趣，今天抽空测了一下，发现了一些有趣的事情。

首先声明这些测试并不严格，全是在同一台机器（Core2 1.6，2G内存PC）上跑，DB是同一个MySQL，执行简单的单表读写操作，并发100个thread（此并发情况下各种技术基本都不会出Error），都不做缓存。数值都是取rps，具体的绝对数值没有考究的意义，不过相对一比较倒有些意思。

先用笔者前两三年一度热衷的Appfuse，测下来的结果大概在130左右；
然后直接采用Spring的三个例程，一来简单，二来Rod自制的Sample效率应当是有保证的，结果如下：
采用hibernate的petclinic：200左右；
采用ibatis的jpetstore：400左右；
采用jdbc的imagedb：750左右。

大家应该看出些门道来的吧。所以说Rod老大的确是聪明绝顶，早已预备了三种不同的性能方案，做成sample给大家采用。至于大家最后怎么用是自己的事，怪Spring就不对了，Rod真是高明！

顺便附上其它技术体系的参考值（由高到低）吧：
纯PHP：1000左右；
以快速闻名的FleaPHP：800左右；
JSTL：350左右；
Grails：50左右；
Seam：20左右；
RoR：12左右。

这下大家是不是有些总的概念了。基本规律是越偏向SQL的技术，性能越高；越偏向ORM的技术，性能越低。由此可见OO和关系DB的不匹配，不仅仅是在设计和编码上，在性能上更是个天大的问题。
差距如此之大，就连笔者也不禁怀疑起自己的测试。建议有心的同道们做一下更严格的测试以资验证。

值得一提的是，在引入DB前，JSP还是要快过PHP不少，大概是1900：1400左右，但加上DB后，JSP竟然干不过PHP，身为Java fans实在是有些愤怒。不过很久不写JSP了，但愿精于此道的同道写个更高效的，压过PHP才好。

现代主流DB在此配置下每秒钟大多能吞下500－1000条普通SQL。做为中间层，不管怎么做，还是要配得上才行。
是选择开发效率低一些，但性能高的偏SQL方案，还是选择开发效率高，但性能低的编OO方案，不同的场景有不同的回答。
但愿此文能帮助各位同道在不同的项目上能对性能－开发效率做出最好平衡的正确选择。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

硬件越跑越快，软件越陷越慢

lgx522 — Tue, 06 May 2008 17:04:48 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/190302 发表时间: 2008年05月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

近日总算有点空闲，走马观花测试了一些技术，包括Grails、Seam、AOM、Python、ZendFramework、CakePHP、Flex、WPF等等，回到JE看了一些讨论，忍不住又要放点黄腔了。

自从多核CPU成为PC标配以后，硬件又上了好大一个台阶。到朋友家看了一下“孤岛危机”，实在是超级惊艳。单位上也终于耗上了一台双核、2G内存，这下跑什么IDE和AppServer都不用去小歇片刻了，真是感谢硬件产商们的努力。

某天看了一篇文章，地址记不清了，却道出了应用程序的本质：“不过就是在数据库里读读写写”，这下便像吃了苍蝇般不爽了起来。搞腾这个行当转眼也七、八年了，回头一想，的确是该反省反省了。

好几年前，更换电脑似乎总是为游戏而换。越来越清晰、越来越眩目、越来越震撼，且不论游戏好不好玩，单声光效果的提高都物有所值。那时候的应用程序其实要求是不高的，VB、Delphi、ASP、PHP这些老革命的IDE和作品，至今可以在怀旧的时候，拿到奔腾166的老机器上去跑一跑，丝毫不见慢。所以那时候更换电脑是与App无关了。

Java引领的虚拟机时代让笔者一度迷了五六年，曾经笔者一度天真地以为只要全面进入虚拟机和中间件时代就可以解决企业应用软件的种种问题，达到高度的业务逻辑重用、高度的异构集成、高度的安全性与伸缩性。这其间折腾的技术、框架加起来怎么也有几十种了，时光飞逝，转眼三十老几了，回头一想，当初的信仰很傻很天真，到头来“不过就是在数据库里读读写写”，最可笑的不过是越来越复杂、越来越慢。看来这些年是陪Sun、IBM、Microsoft以及开源领域的大牛们玩过去了。

由于是在单位上混，出于饭碗的需要，几年来不得不参加了当初以为“不切实际”的软考，一直混到系统分析师。回头看下来，这些个“不切实际”的学究体系其实反倒有些有用处。硬着头皮大体上啃了一遍学究知识，最后才搞明白程序要快要稳定，还是要搞清楚CPU、内存和硬盘；而所谓的可靠性、重用性、扩展性、...XX性，不是靠什么具体的软件技术，而是在于规范的管理与审慎的规划。

缘木求鱼，这就是国内软件业超级混乱的根源。根子上在于我们想偷懒的惰性，明明是我们该自己去思考、去设计、去解决的问题，我们不断地迷信可以依靠“大腕”、“大牛”们来解决。其实连伟大的党都承认了，“没有放之四海而皆准的真理”，何况是软件这种由人造、由人用的事物。结果如何，“大腕”、“大牛”们出于各种各样的目的，不断制造混乱。而我们，正是那随波逐流混水中的泥。

虚拟机时代到来了，动态语言时代到来了，SOA时代到来了，XXX时代到来了，无数吹鼓手吹起了喇叭，震耳欲聋。大家昏头昏脑跳进大大小小的池塘，一边陷下去，一边互相嘲笑、互相鄙视、互相谩骂。好一个热闹的软件大超市。

吹嘘有何用，迷信有何用？最终，还是要抓住硬件这根救人的稻草。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

swt、eclipse RCP与“Java All in One”

lgx522 — Tue, 25 Mar 2008 10:13:08 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/175676 发表时间: 2008年03月25日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

近年来的eclipse与netbeans之争日趋激烈，并不只是IDE争斗那么简单（反正都是免费）。其背后是swt与swing之争，更是IBM所主导的开源Java与Sun所主导的官方Java之争。

搞了四五年Web，冷静下来发觉企业内部应用还是Rich Client好（交互性好、状态管理容易、客户端资源利用度高、易开发等等）。这个事实其实很多做企业开发的同道以至于客户都意识到了，于是出现了很多团队被迫用winform，甚至回头啃Delphi这类无奈的事情。可惜异构调用还是不爽啊，不仅仅是协议转换的问题，还有语法习惯的问题，更要命的是开发思路不同的问题。既然Java是大而全的体系，难道我们就不能始终如一地解决问题吗？
这个问题，其实IBM和Sun也都看出来了，所以不论是eclipse还是netbeans，都不仅仅是单纯的IDE，而是力求“平台化”，争的就是Rich Client的标准问题。
可惜Swing始终是慢，慢到让人心烦，慢到让老一点的机器无法忍受，慢到难以让客户接受（甚至JDK1.6也好不到哪里去）。

好在我们还有swt可用。经过本人多次测试，swt的运行效率其实与winform是不相上下的。
以前由于VE实在难用，而NB嫌慢，Swing和swt笔者以前一直是做手工编码。这一点上说句实在话，Swing的代码是超级优美，扩展类库和控件简直可说是一种享受，可惜还是慢（包括JDK1.6）。
最近由于一个项目要求，要用到swt，于是迫不得以用了一把swt designer（毕竟是D版啊）。这才发觉swt开发原来可以如此之快，几乎达到某些人吹嘘的近似Delphi的程度。而swt designer本身，可说是eclipse RCP的经典范例，功能如此之强、速度如此之快，操作如此便捷，彻底颠覆了笔者过去对Java Rich Client那种“恨铁不成钢”的成见。
回头想起myeclipse、Flex Builder这类精品，这才体会到多年前很多同道对eclipse平台的“野望”。eclipse的确是有实力、有希望成为Rich Client的通用标准开发平台。在此向企业应用开发的同道们进行推荐，希望大家共同努力，让国内swt尽快走出“叫好不叫座”的尴尬局面，尽快赶上国外同行们在此领域取得的成绩。大家可以看一看国外很多利用eclipse RCP搞定的复杂软件，甚至很多项目以前普遍认为是MFC的专属领域；而IBM公司更是把各类软件转向eclipse平台；甚至近日MS都打算染指。eclipse之野望正一步步成为现实。

企业应用“All in One”，不仅是开发者之福，更是企业用户之福。笔者近来年接触的企业应用，大多数都面临孤岛集成的痛苦。主要原因当然是规划不到位、系统分析散乱、数据不统一所造成，但各个时期技术体系不能“大而全”地解决问题也是技术层面的主因。
WS嚷了好多年，至今复杂低效难用，历史一再证明企业内部异构集成不可取。现在我们有了Java这种“平衡至上”且开源主导的技术，有swt能够补上Java一直以来的缺憾，能够做到“All in One”。作为企业应用开发者，我们的确是应该认真考虑并实施“Java All in One”。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

软件开发的实用主义

lgx522 — Thu, 31 Jan 2008 09:08:46 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/160633 发表时间: 2008年01月31日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

本人是实用主义者，所以对软件设计也是采用这种态度。所谓实用主义，最主要的中心思想就是不重过程重结果。

由于本人脑子不是很好使，绕不了几个弯弯，所以在软件设计的过程中都是力求简单直接。

但有一点是很重要的，那就是业务建模一定要认真，非常地认真。本人不会专业的UML，也不用什么Power Design。习惯找张纸开画，或者写在白板上与客户及同事讨论。虽然简陋，但力求真实反映客户需求，最大限度贴近用户业务。多费些时间精力也无所谓，总比最后人家用着难受要好。

至于什么方法、思想，觉得理解得了，用得着的就抓来用；搞不明白，用不着的就敬而远之。比如什么XP，就只用TDD和结对编程。做Java用TDD（层次有点多，不一层层测好了没法做），做PHP或RoR就不用TDD（页面一刷就出来了，写测试完全是浪费）。

还有一点也很重要，软件一定要重构，要反复地重构。一开始我们不可能做得很好，但时间做久了，技术和业务理解深入了，就一定要与时俱进。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

RoR企业应用实践之二：Ajax与维护

lgx522 — Wed, 30 Jan 2008 11:24:11 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/160336 发表时间: 2008年01月30日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

前些天写了“RoR企业应用实践之一：移植物资管理系统”（http://lgx522.javaeye.com/blog/144597），当时还有些缺漏，最近维护中又有些心得，今日有空便补上吧。

1、把系统中界面要求高的地方Ajax化，取得了比较好的效果。笔者开初并没有Ajax开发的经验，便参照“Agile Rails”的“Web2.0”一章进行改造。而这项工作远比笔者想像的容易，很快便完成了内部系统最常用的拼音首码输入，无刷新添加、更新、删除数据行等功能。由此体会到在RoR环境下Ajax开发的便捷。虽然rails自带的Ajax库不多，也不够炫，但非常实用，足以解决大部分B/S界面问题。而且改造的过程中，原先未用Ajax时的代码改动很小，足以表明rails框架设计的合理性。

2、系统上线后，效果相当理想。于是又有提出不少新的要求。如在线申请、审核、签收，多级库房、统计报表等等。于是笔者又对系统进行更新维护。好在系统设计之初，一直严格遵循范式和OOP，数据冗余度极少、代码冗余也很少，且rails的目录结构非常合理，故进行系统功能扩充、改造进行得相当顺利。困难之处在于要对业务的逻辑关系建模得相当到位，之后便可享受rail的DSL带来快乐了。

3、由于笔者对Linux和lighttpd-fcgi不熟悉，故采用俗气的Windows+Apache+Mongrel进行布署。好在系统并发压力较小，架了台普通PC台式机（CPU 2.4G，内存512M），连同MySQL一起跑。实践表明相当稳定，扔上去两个多月都没问题。这里需要说明的是，笔者曾经做过一点简单的压力测试，在50个并发的条件下，能够达到20左右的rps，足以满足企业内部这类中小系统的需求。今后有时间将尝试及时响应、并发要求高的系统，如门诊系统。届时用正规的高性能部署方式，看raisl是不是挺得住。

结论：
1、RoR环境下使用Ajax相当容易；
2、RoR具有良好的维护性，可以满足企业内部业务变动与扩展所带来的需求；
3、RoR具有一定的性能和稳定性，可以满足普通并发与响应速度的要求。

闲话：
近一年RoR和PHP之后，站在书柜前看到那一堆曾经奋战的Java书和另一堆仅翻过数本的.NET书，真是相当的痛心。唉，谁叫咱爱上这一行呢？

实在话：
不是人家不好，而是咱基本上用不着。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

RoR企业应用实践之一：移植物资管理系统

lgx522 — Wed, 28 Nov 2007 17:56:22 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/144597 发表时间: 2007年11月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

前些日就打算开展RoR的实践活动了，见前文“在rails中，多个字段关联同一张表如何做？ ”。在此感谢众热心道友的支持，尤其是sun201200204 的代码圆满地解决了问题。

近两月忙于家事和单位上的诸多琐事，一直未得空闲。近日工作生活终于有点闲暇，才得以静下心来付诸实施。经过近两周的工作，终于大体上完成，算是笔者在RoR上第一次重要的实践，就谈几点体会吧：

1、RoR开发这种中小系统，对于熟悉了Spring+Hibernate+XXX的程序员来说，的确效率惊人。笔者基本上是单干，当初用Spring+Hibernate+JSF作开发的时候，耗掉了两个月左右。除去建模、业务逻辑所耗去的近三周时间外，RoR仍有将近3倍的开发效率(考虑到笔者对RoR的熟悉程度有限)。细下想来，以前用Java开发多浪费的时间依次为：1、配置及布署；2、错误查找；3、多写的代码。其实RoR的ORM、MVC思想与Java是一致的，差别就在于动态语言的优势。所以Ruby可以说是“动”起来的Java。

2、个人感觉RoR的Model这一层比Java中的ORM更上一层楼。简单、直接、清晰，更加适合快速建模与业务逻辑的调整、修改。从这个角度来说，RoR其实是应当在企业实用中发扬光大的。企业应用中，业务逻辑的复杂与混乱历来是个大问题，用RoR的Model来进行建构与变更是相当高效的。

3、企业应用中，很多是联机事务应用，需要快速的界面响应性，这类应用需要用Ajax甚至Flex作表示层来解决。笔者对JS和Flex基本上是生手水平，今后将通过自修及培养其它同事来解决View这层的问题。

经过慎重的实践，笔者现认为RoR是有足够的实力在中等规模的企业应用中获得成功，今后将继续努力的脚步。在此与诸位共勉。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

有了Ubuntu，您还需要Windows吗？

lgx522 — Sat, 03 Nov 2007 11:22:30 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/137740 发表时间: 2007年11月03日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

6年前搞Java以来，就一直以“开源死忠团”自居（包括PHP、RoR，DB、Web Server），却一直在Windows上作开发，深以为耻。然而Linux的桌面世界却始终找不到让我比较满意的系统，只好暂时忍了。

然而Ubuntu的出现及不断完善终于让我如愿。

不再为层出不穷的病毒而烦恼，不再为愈发缓慢的上网而等待，不再为频繁的死机而上火，甚至不用再去到处download各种软件，找各种注册码。
因为我已经身处于一个安全、稳定、高效、方便，自由开放的系统和软件世界。

感谢Ubuntu高效稳定的桌面系统，一扫过去Linux桌面缓慢且不稳的阴霾。
感谢Ubuntu方便快捷的软件安装方式，同时感谢众多无私的开源软件贡献者，感谢apt-get install。
感谢Open Office的进步和完善，终于在大多数情况下可以和MS Office互用。
感谢Java、PHP、Ruby在Ubuntu下更加卓越的性能和表现。
......

日常工作是做系统管理维护，深感系统规模日渐庞大复杂之后所带来的可怕。Java体系学久了之后，才领悟到Windows的系统思维方式是不适合业务系统的。
作为企业用户，我们真正需要的是那种深思熟悉、长治久安的Unix的系统思维，以建构业务系统。企业级系统如同其主干业务，理应拥有专业品质。而不是Windows那种业余的、随意的、娱乐式的思维。

可惜国内目前95％以上的单位组织都在使用Windows建构，更糟糕的是采用Windows式的思维方式来建构。这类系统注定了无尽的错误、Bug和混乱。Windows最适合的领域其实是娱乐（影音、游戏、新闻），娱乐思维统领企业业务，这本身就是个错误。

身为程序员，大家应当首先从这个错误的泥潭抽出身来。学习使用Linux(Ubuntu)，认真领会Unix系统思维和编程方式，切身溶入开源世界。这样我们才能及时获取专业的编程思维及技能、建构高质量的软件，最终以专业的品质服务于企业、单位、组织。

现在已经有1000多万Linux用户，以程序员为主，并以“专业”自居。的确在实践中，要用好Linux，就必须对计算机体系、程序设计有良好的基础和实践。水平越高，Linux用得越好。

所以，如果您想要加入这千万专业程序员队伍，或者想要让自己的计算机应用达到专业水准，那就选择Linux，选择Ubuntu吧！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

我当爹了！

lgx522 — Fri, 12 Oct 2007 16:18:22 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/131387 发表时间: 2007年10月12日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

10月7日，女儿降生，一时间轻松和喜悦充满了心间。

以前看亲戚朋友们的baby，说实在话总觉着太哭闹，比较烦人。今天见到自己的女儿，则完完全全是另一种心境。一见到小宝宝，不论是哭是笑，是静是闹，总是超级可爱。

作父亲是很累的，从入院到回家，整整4天几乎只踏踏实实睡了4个小时。年过三十之后，平日搞成这样是很难支撑的。但这几天，仿佛是从这个小生命中获得了巨大的精力，不停地忙忙碌碌。前夜、昨夜终于得以好好地睡上觉，这才发觉疲累不堪。

我用奶瓶喂了小宝贝两天的奶粉后，前日老婆开始努力喂奶，非常艰难。听着小东西不停地哭号，很是不忍。经过不断的努力，终于一点点地得以进步，一点点地得以成功。看着老婆散乱的头发、满身的大汗，再瞧瞧小宝宝喝足后闭上眼满足的表情，突然有一种很大的成就感。

由此感慨生命的美妙与精彩。正是在这样的美妙与精彩中，生命得以不断繁衍，不断进化，生生不息。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

伟大的Hessian

lgx522 — Fri, 05 Oct 2007 15:10:47 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/129194 发表时间: 2007年10月05日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

前几日看过道友lordhong的文章“Hessian开始支持RIA了（JavaFX和Flex）”(http://www.javaeye.com/topic/125573)，便到http://hessian.caucho.com/上访问了一下，仔细一看才知道Hessian已经远超期待！

Java、Flash、Python、C++、.NET C#、D、Erlang、PHP、Ruby，看看伟大的Hessian当前所支持的语言吧！

原先看经典的“without EJB”，讲到Remoting时，便有对Hessian这一“Java to Java的轻量级协议”的支持。实践中Spring使用Hessian、Burlap、RMI、HttpInvoke非常简单，并且Hessian、Burlap的性能相当高，仅仅稍逊于Java专用的RMI。当时笔者对此稍感遗憾，这么简单高效的协议，如果能支持其它的语言该多好！

想不到仅仅两三年之后，Hessian便几乎囊括了当前最主流、最火爆的语言！

自从计算机世界的数百种语言不断诞生以来，IT界便陷入了巨大的烦恼中：一面是多种语言带来的丰富多彩和各自擅长领域的卓越表现；一面是“信息孤岛”的爆炸性增长和各类技术间激烈的争执。异构集成已成为至关重要的事情。

但问题在于缺乏标准和协议。

于是COM、CORBA、EJB、SOAP不断涌现，但这些由厂商和委员会们搞出来的东西，注定只能钻进那5%的“超复杂”胡同，高度的复杂性与低劣的性能，最终也只能让大家“曲高和寡”罢了。于是IT界继续争斗与混乱。

应用程序做久之后，大家就会认识到，在大多数情况下，我们真正需要的是足够简单高效的协议，可以很快地写出来，很快地连起来，并且可以很快地运行。于是REST开始放高调了，这就免不了要和SOAP开战，最重要的实践却反而放在一边了。

好在Hessian实实在在地作出了回应！看来要想实现IT世界的统一，必须要靠开源领域中立的的实干家。

如果都能以这样公正中立的路子走下去，大家真可以求同存异了。想想吧，服务端是强而稳的Java，客户端是容易高效的Flex、ASP.NET或者Ajax；或者用PHP、RoR快速构建服务端，再用J2ME、.NET Mobile搞无线；某些特殊场合，使用VB、C++、Delphi这类高性能的桌面程序……。这样的世界多美好！何必成天吵嚷“XXX将要灭了XXX”这类无聊的话题，担心所谓“技术路线”选择。大家各自精通专项技术，然后通力合作，共营IT世界，这才是唯一正确的选择。

人类世界已经趋向于沟通合作，IT世界也应该全面沟通合作了。

这个世界上，有人忙着赚钱，有人忙着出名，有人忙着吵架，有人则忙着做事。干实事的，真该学一学Hessian。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

在rails中，多个字段关联同一张表如何做？

lgx522 — Fri, 27 Jul 2007 11:04:37 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/106060 发表时间: 2007年07月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

这几天笔者投入了ROR的实践中，开始重写2年前用appfuse(Spring+Hibernate+JSF)写的一个物资管理小系统。原因无它，自产自用，业务逻辑成熟，并积累了一定的数据量。

刚一开始就碰到个也许是简单的问题吧，花了点功夫没搞定，在此请教同道：

用户信息简单地存储在users表中，主要字段为：id,username,password,real_name
设备购买主记录表为eq_buy_master，涉及到关联的字段为：manager,buyer,accepter,operator
因外键都关联到users，故无法使用超方便的user_id。
于是在User中设has_many，写法为：
has_many :eqbuymaster
EqBuyMaster中设belongs_to，并仿“Agile Rails”中第231页的做法，如下写：
belongs_to :user, :class_name => 'User', :foreign_key => 'manager'
于是在_form.rhtml中用select的写法为：
<%= collection_select(:eq_buy_master, :manager, @all_users, :id, :real_name) %>
在show.rhtml中显示realname的写法为：
<%= @eq_buy_master.user.real_name %>

使用正常。

但此处有四个字段都关联，这种做法在_form.rhtml中是正常的，但show.rhtml中显示出来的全都是:manager关联的值，显然不对。在EqBuyMaster中的belongs_to部分用过[]或{}，都会报错，不知如何写？
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Java、RoR、PHP，一个都不能少

lgx522 — Tue, 24 Jul 2007 12:57:34 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/104700 发表时间: 2007年07月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

前几年一直弄Java，半年前跟风用过一段时间RoR，最近在搞PHP。
现体会如题：Java、RoR、PHP，一个都不能少。

各种程序设计语言最终的归宿，其实是由最初的设计思想所决定的。
C定位于底层，成就了时至今日的底层霸主地位；VB的初衷就是让Windows开发简单易用，故至今仍然占牢其地盘；Java最初瞄准的是跨平台和解决复杂问题，这一目的已然达到，并正在发扬光大；PHP则是追求简单、直接的Web开发，这一出发点成就了其互联网应用霸主的地位。那么RoR的优势是什么呢？笔者从实践中体会到，其根本的优势在于让OOP变得简单规范。

笔者在三个月前发了“RoR的正确定位”（见http://www.javaeye.com/topic/75167）后，便投入了对PHP的实践中，体会如下：
1、PHP极其简单直接，对GET、POST、SESSION、SQL的直接操控可以适应多种页面需求和变化；
2、传统的PHP是过程式函数编程，简便灵活，但结构化、规范性不足。PHP5以后引入了OOP，框架也火热一片。但两种方式混编容易造成困扰，且框架编程发展较晚，尚未形成成熟统一的实践（如SSH）；
3、PHP入门极易，笔者以前一周即学会，一个月基本上能应付小系统开发，这对于个体户和小作坊这类的开发群体无疑是最适合的；
4、PHP发展多年，类库和API极其丰富，能满足多种需求。
5、空间超多，布署代价极低。光这一条就可成为很多小系统的最爱。
综上所述，PHP是小系统的首选，某些特殊要求的页面也可采用。

RoR在JE上已经火了一年多了，其间无数论战，而RoR的爱好者们至今坚挺，这足以说明RoR不只是花瓶或玩具。在实践中，笔者体会到RoR的特点如下：
1、RoR的威力最主要的来源是“惯例重于配置”，而其“惯例”基本上是多年来Web开发所积累的最佳实践。大家不要小看了这种规范性，所谓“不以规矩，不成方圆”。像应用MS技术的团队，大家不要再胡思乱想，只要遵循MS的标准和规范，即可开发出不低于业界平均水准的系统。
ruby本身是极其灵活的，容易导致混乱，但rails这种天才式的框架解决了标准化的问题。大家不必再为了一个问题去参考十多种方案和实践，浪费太多的时间和精力。在RoR，方案只有一种，而实践上也只需搞定depot即可过关。从数据库设计、ORM、MVC以至于目录结构，全都是统一的。这实在是省心省力，时间和精力都可以放在业务逻辑上了，这不正是以前J2EE和.NET所宣扬的吗？
2、RoR相对Java和PHP这些老前辈，火得比较晚，类库还不够丰富。这就需要大家充分发挥聪明才智，并积极向开源社区作贡献。这一点希望RoR铁杆们多努力，让RoR的类库在未来三五年内达到Java和PHP的水平。届时RoR能不能向Java和PHP全面叫板，未为可知。
3、缘于RoR良好的结构化和OOP，建议大家做中型新系统时采用RoR。历史系统大多数数据库设计不符合RoR的惯例，手工配置会浪费太多时间，不如下点狠心重新设计，一劳永逸。
综上所述，RoR应当在中型系统取得成功。如果你已经习惯了OOP、ORM和MVC，那就一起努力吧！

Java在大型复杂系统的优良表现有目共暏，最主要的是“强”和“稳”，本人不再多述。各位Java同道在RoR之余，大可钻研一些深层次的复杂问题，以应大型系统集成的需要。

谈了那么多，全是可以跑在Linux上的开源或准开源技术，原因在于笔者在五年前已加入开源技术的死忠团。但这几年，每当有困惑的时候都学一些C#这类的技术。C#在笔者看来，定位在于大小通吃，表现比较中庸。也就是说做小系统不太繁，做中系统不太难，大系统也可以做。但中庸也是要付出代价的，这导致用C#做系统不如PHP直接灵活，中型系统不如RoR规范统一，大系统不如Java强健。
当然，实践中还是有很多MS的死党，如果您对MS技术的安全性和稳定性抱有足够信心的话，C#的确可以达到一次学习，多方适用的目的。

开源领域，要想学一种技术大小通吃，很多时候必须一钻到底，承担类库或框架开发的责任。由此可以产生专项技术超强的高手。而如果您同时掌握PHP、RoR、Java，也可以比较小的代价做到大小通吃，快速搞定各类应用开发。何去何从，应该由开发者及团队所面临的环境和场景而定。

一项专精，还是三者兼备，相信聪明的读者已经有了答案。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

看好Ajax＋WebService

lgx522 — Tue, 10 Jul 2007 18:32:16 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/99853 发表时间: 2007年07月10日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近“退步”了，在用PHP，看过“Ajax和PHP开发Web”之后，又接触了些Ajax库，尤其是YUI-Ext给我的印象很深。照此发展下去，本人预感Ajax将是C/S vs B/S这场战争的最终胜者。

Ajax虽然暂时用起来比较繁，但开放性好，对客户端要求低。当Ajax残酷的类库大战硝烟散尽之后，必有一王者成为客户端的统治者。即使从目前来看，Ajax中比较成熟的部分，也已经成为各网站的首选。而Ajax在企业内部的应用，也只待东风了（易用性和IDE）。

原先嫌Ajax繁，一直不理会。投了半年左右的精力在RCP上，作了一些Eclipse RCP、NetBeans Platform及WinForm SmartClient的实践。始终都不太满意，以致于怀念起VB、Delphi + COM。这才深刻体会到Ajax的两个最重要的优势，于是开始学习Ajax。
客户端技术发展到今天，功能大同小异，各有千秋。突破这种各自为政的混乱局面，是这些年技术大爆炸的根本原因之一。要想一统江湖，最终靠的是标准。
想当年Windows平台下应用程序开发无比繁荣，靠的正是Win32API。Win32API之所以成功，源于在Windows平台下的强制标准化，本身的高性能以及一定程度上的易用性。
而后的网络泡沫时代，亦高度繁荣，也正是源于HTML的标准化、高性能和易用性。
之后进入了Java和.NET的虚拟机时代，这一时代在服务层取得了重大突破，但表示层却始终尴尬。原因正是在于标准不统一、性能低下和易用性不高。由于不成熟的表示层技术不断引入，导致混乱局面不断升级。
而如今，Ajax日益流行和成熟，我们也许有机会结束这个混乱时代了。

之所以看好Ajax，正是因为它满足了两大要求：标准化和高性能。Ajax中涉及的JavaScript、XMLHttpRequest等技术，不论如何已经成为Web应用中不可或缺的角色，而各类型的浏览器都提供了支持，虽然有一些小的差异，但大方向上容易形成标准。Ajax对客户端的要求最低，既可以在高性能机器上提供大而全的支持，也可以在老掉牙机器上提供小而精的支持。以前Applet在JRE无预装之后即告退化，足可以说明其重要性。
与Flex和WPF不同的是，Ajax是完全开放的。也就是说大家都可以按照他的要求形成自己的体系和利益群。过去的Java和.NET已经足够大而全了，可惜人们还是要二选一，时至今日都难以抉择，令人惋惜。
至于易用性这一点，目前的Flex和WPF虽然暂时领先，但Ajax只要类库竞争尘埃落定之后，决非难事。过去的Struts即可为证。

顺便谈一下服务器端吧。WebService目前虽难用，但标准化是满足了，足以形成服务层的标准。现在的问题是：是采用官方版的标准SOAP，还是采用民间版的简化REST。这可能要依系统的规模和复杂度而定。不过这下我们身在服务端编程各个阵营的同道们大可放心了。不论是Java、.NET、PHP还是Ruby，只要采用WebService就可以实现互通互连，思路上总算是功德圆满了。实践中却还要解决性能和易用性的问题，虽然WebService达不到专用协议（如RMI）的效率，但为了异构系统集成和长远的扩展性，这点牺牲还是值得。我们要做的就是如何在自己的平台上把WebService用好，尽最大努力解决性能和易用性问题。

这几个月总见dlee等人宣扬REST＋Ajax，先也不以为然。待笔者重走长征路后，才大体上得到了类似的结论。虽然晚了些，却是笔者的真实经验与感悟，在此与诸位共勉。

本人今日之愚见且认为：Ajax＋WebService（或者说REST）最有可能成为表示层与服务层的最终标准。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Java的表示层，到底该怎么办？

lgx522 — Mon, 02 Jul 2007 15:15:11 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/96921 发表时间: 2007年07月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Java做老大很久了，而Java的表示层难用也已经很久了。

经过数年的折腾，Java已经证明了自己在服务器端的巨大优势，“强”而“稳”，高扩展、高安全、高维护。实在是面对复杂应用的架构师之首选。
此外，Java起家时一直所追求的平台无关，也瓜熟蒂落。有跨平台需求的各大产商们，纷纷用平台无关的Swing构造自己的基础软件产品。各类智能设备，也都大量应用Java技术。
不论如何，Java确实已经成功地证明了自己。这种虚拟机层面的技术亦将长久地生存发展下去。

然而再伟大的技术也有缺憾，正如伟大的C语言始终难做GUI。而Java最大的遗憾，也是在表示层。

表示层变化太快了，以至于多高深的理论也总是在这里碰钉子。反倒是缺乏“技术含量”的入门技术不断地在现实领域获得成功。VB、PB、Delphi、ASP（包括ASP.NET）、PHP、JavaScript、Flash，正是这些不够OOP的东西，这些不需要奢谈“模式”的东西，总在刺激着理论家的神经。或许这一块，本就是人民群众充分发挥想像力和创造性的领域，正如一切高深的社会经济理论，在现实世界的发展面前总是那么苍白无力。

表示层的工作还是太大了，循规蹈矩的好学生Swing，总是搞不赢WinForm这类时常开点小差的差生，更是远远不如他的前辈VB、PB这些小流氓。而高傲的Java Web层，凝聚了各种“模式”的精华，还是难以承受ASP、PHP这类无法无天的混混之冲击。毕竟在表示层，计划不如变化快，什么继承、封装、重用，在现实中其实并不重要。因为很快就地震了，一切都要重盖了。说实在的，这个领域，只要少出点Bug，多设计不如少设计，因为后者来得更快，而且更容易找人来做。

这个结论可能很多要引起公愤了。不过别急，大家回头想一想，以前大家做这行的时候，不是流行说35岁就Game Over了吗？可坚持到这把岁数的老同志其实现在很值钱。他们在做什么？在做服务端、在做底层、在做设计。这些高级的活儿，不干够年岁，不见多识广是做不了的。
即使是做表示层的，那是在做研究（如dlee），而非拖拉控件这种事情。

至此，笔者斗胆做一结论：表示层要成功，拼的是易用性。类似的功能条件下，谁简单谁赢。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

近日关于Java简单与复杂的总结

lgx522 — Thu, 24 May 2007 18:07:03 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/82642 发表时间: 2007年05月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

前一阵子为软件简单与复杂的这个难题思考了很久，技术架构上痛苦徘徊了不少时间。其间产生的一些反动言论，被大牛们一阵暴踩。其中也多有启发之处，在此致谢。

近日总算有了个结论，其间重啃了一遍without EJB，重构了一些系统中的部分代码，做了几个关于RIA的垂直切片试验。

理论上的总结本已有文（题为“坚持发扬EJB、Spring的光辉思想，将组件化进行到底！”），但观点比较激烈，为避免引起论战，此处先不发了，有兴趣的看jdon头条。

实践上的总结很简单：

1、企业应用是复杂的，保持业务逻辑的稳定、扩展和重用极其重要，因此分层要清晰，设计要到位。不能因追求开发效率而牺牲软件质量。

2、Spring是当前大多数企业应用最适合的基础架构。应当简化的部分，Rod已经做了简化；再进一步简化（比如砍掉某些层、接口、配置文件）虽然可以提高开发速度，但适应性会大大降低。遵循Spring设计思想及实践的应用程序（甚至桌面程序）可以极大地降低软件的耦合度，可以方便地提炼为组件重用。

3、建议还未达到大牛水平的同道们重温Core Java、Think in Java、Gof和without EJB，深入钻研、努力实践Spring。如果有一天Spring这一伟大实践的应用程度能达到像当初VB、ASP那样普及和熟练的时候，国内的软件业必走入辉煌。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

RoR要在企业领域成功，必须过实时性这一关

lgx522 — Thu, 17 May 2007 18:05:34 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/80659 发表时间: 2007年05月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近在弄RoR，几乎也快成Java的叛徒了。
谁让RoR做Web+DB就是Easy呢？一个字，爽。

由于本人的工作实际上是在医疗行业做系统维护的，工作时间成天面对的是那些个讨厌的PB程序。有的时候就在琢磨，什么时候能不能有公司也用Java或RoR做一套完整的HIS，来取代这些个五花八门、乱七八糟的C/S程序，达到信息资源整合的目的。
前阵子见某公司用C＃搞过一套，还是很成气候的。不过本人对MS早已敬而远之了，加之实际看下来，性能不过了了，才知道.NET的后台处理能力是不如Java。

医疗行业的业务系统，对实时性要求很高，这是导致技术上过时的C/S系统继续垄断的重要原因。尤其像门诊相关的系统，几个延时下来，操作人员恨不得把机器扔了。PB这类C/S技术做的系统，代码设计之烂惨不忍暏。从长远看来，极难维护和扩展，重用则基本不可能，但眼前的实时性还是满足的。所以，当前医疗行业的信息系统，普遍存在着这样的尴尬局面。

曾经考虑过以Java作为解决方案，即业务操作为主的部分采用Swing或Applet作界面，查询为主的部分采用Web。这种方案最适合的技术无疑是被打入冷宫的EJB（不得不说，EJB一开始就把桌面程序和Web并重，的确是深知企业的需求，企业的业务系统的确不是当前Web的实时性能够满足）。Spring做后端是比较简单，可惜一上来就是冲着Web去的，RCP并不成熟。
这几天开始接触EJB3了，发现比以前简化得多了，不知能不能满足以上需要。这个问题请有经验的同道们一起讨论。
前些天看一些同道用Java后台+WebService+WinForm做前端，本人实在觉得不妥。其实Swing开发起来及运行速度不比WinForm慢多少。结合RMI比WebService快多了。看来自从倒EJB运动以来，大家对EJB以至于Sun的官方技术几乎形成了一种歧视，这完全是没有必要的。Sun以前的技术在重量级领域非常之优秀，只是大家大多数情况用不到。现在开始着手经量级了，大家还是应该尊重一下。

RoR做Web那是没得挑了。可惜企业业务系统的实时性要求就如游戏，稍微慢一点就爽不了。即使用现在流行的Ajax，开发起来繁得很，最后的速度和C/S还是差几个数量级。这样的程序拿到企业，最终还是很难说服领导，因为领导们不关心你用什么技术，他只关心能不能更好更快地解决问题。
所以建议JavaEye的诸位同道，不要成天盯着Web。说实在的，internet领域容不下那么多的就业人员，也淘不出那么多金。
解决企业的实际问题，当是大家未来的前途所在。
建议JavaEye同仁多在RCP下些功夫。

最后说到RoR，如果它能够很好地解决实时性问题，即一方面是表现层的响应速度，一方面是高并发访问的容量，那么我们大家真有必要把它引入企业。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

RoR的正确定位

lgx522 — Thu, 26 Apr 2007 18:02:25 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/75167 发表时间: 2007年04月26日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近由于工作原因，用appfuse、asp做了些东西，猛然间又怀念起四个月前学习的RoR，这才领悟到了RoR正确的定位。

自从RoR开始流行以来，一直就口水战不断。原因何在？其实就在于不知道国外大佬们作何感想，一上来就把RoR的矛头指向了Java。Java是大家热爱了很久的老大，MS炒了好几年的C#都动弹不了它，说明其在稳定性、规范化、应用范围上是具有统治力的。RoR本身是相当优秀的，可惜指错了矛头，反倒搞得四处树敌，难以推广。
笔者在几个月前接触RoR的时候，有个大体模糊的感觉，认为它应当是asp、php的劲敌，经过这几个月的实践，更加坚定了这种想法。

RoR为何会在J2EE程序员这个群体中火热起来，甚至让很多人倒戈？原因就在于大家吃够了J2EE的苦头。扔掉了分布式的EJB后，大家拥抱Spring，而Spring+XX+XX+XX的模式也还是太复杂了。它们的复杂，就在面对的是真正的企业级开发，要考虑太多、太远，稳定性、高性能、扩展性、异构系统集成、遗留系统重用、多种客房端等等，全是一堆头让人头疼的事情。需求如此复杂，技术架构自然就复杂了。而国内大多数吃J2EE这口饭的，90%的情况下所面对的，都是Johnson所说的那90%的简单问题，说白了，就是用Web+DB就可以解决的问题。而这种场景下，RoR是当前最好的OOP解决方案。

RoR与ASP、PHP一样，都是为Web+DB量身订做的。在这个领域，动态脚本语言有绝对的优势。
JSP刚开始跟ASP、PHP在internet领域闹腾了好几年，结果还是干不过简单的后两者。时至今日，MS的“弃儿”ASP在国内的网站仍占统治地位、PHP则在欧美一路领跑。这缘于internate领域业务的快速变化性，那些编译来配置去来回折腾的技术实在浪费了程序员太多的时间精力。这些快速变更的东西，我们要的是用editplus修改之后，浏览器刷一下就可以看到结果。在这个领域，我们不需考虑那么多复杂的事情，我们要的是简单快速。所以即使如ASP.NET封装得那么好的tag，到头来还是不如HTML嵌代码好使。
所以在Internet领域，我们需要的还是动态脚本。

作为J2EE程序员，我们历经了多少探索和磨难，好不容易习惯了OOP，习惯了ORM，习惯了MVC。走尽万水千山路之后，当我们发觉做Web+DB竟然不如当初甩到一边的ASP、PHP时，真是无比沮丧。那是否意味着我们要回到ASP、PHP或者纯JSP呢？答案自然是否定的，因为RoR出现了。
它可以让习惯了OOP、ORM、MVC的我们继续宝贵的设计思想，以不低于ASP、PHP的效率开发出结构合理、统一规范的Web+DB，这正是RoR的可贵之处。
唯一令人遗憾的是，我们又必须学习一门语言了，而且是小日本搞出来的Ruby。一门语言入门容易，精通则难。想当初弟兄们不知费了多少宝贵的日日夜夜才把Java练纯熟啊。不过想想那帮费力气练熟了VB、VC、ASP、WinForm的MS同行们吧，它们不是更惨，不但语法变了，连设计思想都变了，MS太不厚道！相对起来，Java时至今日仍保持良好的兼容性和技术延续性，就凭这一点，我们也应该继续支持Java。同时，为了在近两三年内（Groovy和Grails真正成熟起来）不让那90%的Web+DB继续痛苦，我们的确应该暂时用RoR来了。

近日终于想明白了这一点，在此与各位共享。
愿各位弟兄们早日用RoR搞出几个像样的CMS、Forum、Blog、Eshop、Email这类俗气但广泛应用的东西，并成功发展出一片价廉物美的RoR主机空间。这样的话，RoR一定可以走出现在这种叫好不叫座的局面。
至于原先真正的“企业级应用”，还是继续发扬静态编译语言的优势，好好站稳Java的脚，免得被MS趁乱了夺了去，那样的话，将是整个开源领域的灾难。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

有感于“以复杂性为生的行业”

lgx522 — Tue, 24 Apr 2007 17:11:50 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/74169 发表时间: 2007年04月24日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Rod Johnson在“without EJB”中说了很多真诚的话，其中就有“以复杂性为生的行业”这样的说法。

说句实话，大多数B/S系统用asp、php就可以轻松搞定，而大多数C/S系统用传统的VB、PB、Delphi也很容易完成。硬件要求低，开发周期短。也就是说，90%的问题都可以用这些简单的技术解决。
可是，asp、VB太easy了，easy的东西自然就不值钱了。于是国际巨头们盯住了那10%，声称必须运用新一代的高级技术，如J2EE、.NET等等，可以轻松解决所有问题。新的价值链得以产生，巨头们又开心了。而程序员们怀着极大的期望投入新一轮的技术竞争。但结果是，为了那10%的复杂问题得以较容易地解决，我们把原先那90%的简单问题变得复杂。这正是笼罩在软件业头上的一道魔咒。

本人原先一直是新技术的狂热爱好者。好似一个新技术的追星族，精疲力尽之后才明白新老技术的共通性。其实做应用系统，你是用asp还是J2EE并不重要，重要的是你对业务的领悟能力和对技术的运用能力，而这种精通的功力是需要很多时间及经验的。有些业务是该重型武器，你得上J2EE；有些业务却是asp这样的小刀来得顺手，不可一概而论。asp用得精纯，也可以做到相当高的稳定和性能，以至于好的扩展性和可维护性；而生手弄出的J2EE，很多时候跑都跑不起来，再大的口号也是白费。
总之用什么技术并不重要，重要的是你熟不熟，精不精。整个IT技术圈子如果不能有这样的共识，就只能活跃着一大群满口新鲜术语的菜鸟，搞出一大堆费钱费力的豆腐渣工程。而国内的IT界也只能在这种烂泥潭中挣扎下去。
一个雕塑家好不好，没有关心你用的是凿子还是激光。大家评价的标准是你的作品好不好。
同样，软件好不好，也不应看你用的是asp还是J2EE，用的是过程式方法还是OOP。唯一的标准应该是软件产品本身的质量，即稳定、高效、设计合理。而程序员的价值，也不能以运用什么技术予以衡量，而应以分析解决业务问题的能力而定。只有这样，软件界才能走上良性发展竞争的道路。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Java Web层的下一个王者是谁？

lgx522 — Thu, 19 Apr 2007 17:47:33 +0800

作者: lgx522 链接：http://lgx522.javaeye.com/blog/72538 发表时间: 2007年04月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

经过数年的“框架大战”，Java界的各种框架找到了自己应有的位置。

Spring+Hibernate+Struts已成为Java开发的主流体系。在这个体系中，Spring+Hibernate的地位应该说短期内是难以撼动了。除了新兴的Jboss Seam作为挑战者之外，几乎难有劲敌。有趣的是当初Spring、Hibernate作为挑战者，将官方的EJB成功挑落马下；这次反倒是官方的EBJ3成了挑战者，不知结局如何。

Java B/S编程中历来战火最激烈的其实还在Web层，框架的数量最多，争议最大。
一切由Struts而起，而Struts最终也坐稳了第一个时代的王座。在技术层面，Struts 1.x已经被无数人抱怨过、批评过，但终于还是稳坐王位，这充分说明了习惯的力量。“稳定压倒一切”，这句话在IT技术领域仍旧适用。
其实IT应用技术，什么新鲜玩意并不难学。难的是标准化和规范化。每个程序员都有自己的思路和习惯，写出来的代码自然是五花八门。Java何以成为编程界的老大，很重要的一点在于Java的规范化。这种规范化很高的语言适用于多人合作的大型项目，便于沟通和理解，也就便于集成和维护。Java世界为什么会框架横飞，说到底还是规范化的需要。纯JSP和Struts写Web谁快，摆明了是JSP。那撑饱了用Struts？原因在于100个人写出来的JSP，有100种写法；而100个人写出来的Struts，基本相似。Struts之成功，正缘于其在Java Web层的规范化方面所做出的贡献。

然而长江后浪推前浪，Struts 1.x的技术缺陷毕竟是隐患。
Sun力推JSF，打算一雪Web层框架缺失之耻。可惜JSF既要沿用Swing的技术路线，又要学ASP.NET，还要照顾产商的IDE，结果搞了个四不象，弄得里外不是人。当然Sun的技术实力毕竟是超强的，只要别重蹈EJB的覆辙，拿出点专断的精神（像这两年的NetBeans），做出像Swing那样水准的东西，JSF当大有作为。JSF现在比较有优势的是对Ajax的集成，这一点走在了其他框架的前面。

而Struts就更没有志气了，把WebWork换了个标签，凑出个Struts2，Bug多多。说实在话，根本不如原版的WebWork。如果不是靠了原先的fans捧场，根本就没得混。不过Struts原本就不是以技术取胜的，靠的是抢占先机带来的习惯优势。如果原先的fans们在这两年内都能转到Struts2，那么Struts二世仍将雄霸天下。

综上所述，未来两年，JSF与Struts将展开Java Web框架的最终战争。
以笔者愚见，结局有二：一是不论Struts还是JSF获胜，Java Web层都将结束混战的局面，这对Java Web开发的标准化是非常有利的，并有助于巩固Java在B/S界的地位；二是Struts1.x、Struts2、JSF三分天下，必然从整体上削弱Java在B/S界的竞争力，并将进一步被RoR、ASP.NET、PHP所蚕食。

有兴趣者参加讨论。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐