Java的表示层,到底该怎么办?

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),而非拖拉控件这种事情。

至此,笔者斗胆做一结论:表示层要成功,拼的是易用性。类似的功能条件下,谁简单谁赢。


Java的表示至今为何不成功,根本原因在于大师及牛人们沿袭了一贯的高技术路线,一个个拼思想、拼设计、拼架构,最后苦了开发者。
这个事有前史可供借鉴:当初大家最终发现实际工作中基本上用不上EJB,于是Johnson振臂一呼,来了个倒EJB运动,终于甩了一大包袱,让Java在服务器端来了个大胜利。不是说EJB一无是处,而是大家基本上用不着。

以前ASP、PHP、JSP争霸的时候,很多同道其实是选了JSP,为了一点高技术含量的满足感和高薪水的诱惑。后来才发觉JSP用起来复杂多了,于是很多同道就不断制造Framework,以图用规范化解决复杂性,可惜事以愿违。现在回过头来看,Java Framework在数据层的成功(Hibernate),在服务层及全构架的成功(Spring),实际上是突破了所谓的“J2EE规范”,极力简化的结果。而Web Framework的不成功,则是在重蹈经典J2EE的“规范化”不归路。

以前史为鉴,我们所需要的,应当是简单的表示层。换言之,至少不能比JSP更复杂。现在大家都已经养成了好习惯,数据层和服务层的代码都放到应在的位置了。说句不中听的,只要数据层和服务层质量高,表示层乱一点没关系,重要的是足够Easy。看着不顺眼没关系,重写一个就行,费不了多少工夫。当年VB、PB、Delphi就是这么干的,他们不过是败在业务逻辑和表示在纠缠在一起,难改,一动百摇。


有了基本的思路,那该如何做?思路如下:

1、用纯JSP调服务层。主要是考虑JSP的广大群众基础。如果有条件的团队可以用velocity、freemarker,这样可以像ASP、PHP那样改起来查看快。
2、用Swing或swt调服务层导出的远程接口。像Spring的远程调用,方便之极,不过是在服务层的xml中写点东西,copy一下改一改很快。Hessian、Burlap和RMI都很快。缺点在于都要装JRE,对机器要求高一点,老掉牙的机器有点难跑。此方案适用于对客户端要求高的企业内部应用。
3、用Ajax,就像dlee这阵子提的Java REST,我是不会啦。感觉还是比较复杂,不太适合人民群众。
4、等JavaFX...
5、等Java界下一个即简单又规范的Web Framework...
6、发动VB、Delphi、PB高手,解决调用Java服务的问题(只是千万不要用Web Service,又复杂又慢),这其实是一个最疯狂最厉害的方法。如果真能解决,以VB、Delphi、PB的高用户群、超强群众基础、快速而低配置要求,配之以强大稳定的Java服务端,服务端与客户端都得到充分的利用,必定能打造最强企业应用。而各位老鸟也可专心做高级的服务端,新手乐之于低级的客户端,各得其所。这事情其实最理想,只是难做:1、各大产商是以新而复杂的技术为生存基础的,这种对客户有利的方案势必被其打击和歪曲;2、国内的高人们其实都是唯洋大师马首是瞻,生怕脱离潮流影响生计。

第6条,有心有志的同道们可与我联系,大家一起尝试一下。
此文在JavaEye也发了,希望可以在国内这两个比较权威的论坛找到知音,大家一起来解决Java的表示层问题。
[该贴被lgx522于2007年07月02日 17:11修改过]

>我们所需要的,应当是简单的表示层。换言之,至少不能比JSP更复杂。
Jsp说复杂就很复杂,嵌入java代码就变得复杂。
Jsp说简单就简单,没有Java代码就是XML了。

我想楼主的意思应该是:简单的表示层,至少应该是简单XML。

个人观点,表现层复杂其实和用户体验相关。用户需要漂亮的界面,通过专用设计工具设计后就是XML,然后再嵌入一些struts那样精简的标签库,问题的复杂性就出现在这里,页面Html是工具生成的,需要程序员在复杂的html加入标签,是一个考验,不过还是可以通过Tiles等框架来简化。

java表现层现在最大的问题是动态性,这也是AJAX受欢迎的原因,相信随着Serlvet 3.0出台,WEB对动态性支持更全面,Java表现层就能够更丰富。

http://www.jdon.com/jivejdon/thread/32148.html

这篇帖有两个议题:
一是以JSP做表现层不如动态语言(PHP、ASP)简单,表现力强,导致有点“曲高和寡”,以至于在internet领域总是叫好不叫座。不知是否能用刚起苗头的groovy这类东西解决问题。

二是banq说的“java表现层现在最大的问题是动态性”,这是导致Java在企业内部应用中尴尬局面的根源。大家对Java服务端的“强”和“稳”难以抗拒,却对客户端的“繁”和“弱”望而却步,比如说客户大量要求的报表就始终很难做。这个领域,如果本人说的第6条理想无法施行的话,就只能发展Swing,让客户抛弃老机器了。

至于彭老大说的Serlvet 3.0,没接触过。望有经验的同道介绍一下。

java的web应用很难么 没感觉
<%%>全部用JSTL标签来替代
然后跳转,简单逻辑等部分由struts来负责 struts2.0相当简单好用


如果有一定的技术积累,可以用JS 来开发WEB组件 通过拖拖画画的方式就可以构建页面了, 整个HTML BODY就是一个大DIV 在上面想加什么就加什么
象DOJU DWR等等 已经出现很多这样的框架 只是功能都很有限 只是一些最简单的应用

Struts2.0有点慢,时常还蹦出点小Bug,感觉不如原版Webwork。

大家好,我是Thinkinjavax.初来贵地,也说两句。
1:关于swt、swing、netbeans
swt的确优秀,可它只是在windows下速度快一些。swing换上好的look&feel后也很漂亮,而且linux也可以跑。曾想写swt插件,可发现它所有的基类都是自立门户,很不爽。最后跑到netbeans下面去写了。看来将来java开发工具就是eclips和Netbeans一争长短了。

2:关于上面提到的swing要解决调用服务层的问题
我想这不是swing要解决的问题。java本身是所有语言中支持网络最好最强的。它就是为网络而生的。java.net包里有多少类呀,用都用不完。如果是个有上进心的java程序员,稍微用些功夫就可以写出一个通用性好,易用性高的网络层来。
Swing本身,对于只会写jsp,asp的人来说,学起来难度是很大的。它是100%对象化的,纯粹得有些过份。而对于C++程序员来讲,却是一个福音。有知有人认同我的观点吗?
Swing要解决的是应该是组件要多一些,在企业应用中的数据输入、数据展示这一类组件应该丰富一些。就像当年的vcl。

4:Swing缺少什么?
要用swing做企业应用开发,有个非常致命的问题,它的数据处理能力太差了。这点离当年的VB,Delphi差得很远。更不要说PB了。用过PB的人都知道,它的那个“数据窗口”太强大了。
我们我们应该下功夫去解决这个Swing致命问题,加强它的数据处理能力,在网上还看到好多人拿JTable显示和输入数据库数据,我伤心的很。难道就是这样用java的吗?这么个用法,难怪会有人说java又慢又差呢。

5:java的前景非常好
其实java前景非常好。服务端不用说了,大型机小型机中型机全能上;现在呢,客户端也是成问题。我自己形成了一套成熟方案,开发起来速度不比VB慢,Delphi慢,却比不上PB。但服务端却是发布于Webspere的,客户端用的是WebStart+Swing。

http://hi.baidu.com/thinkinjavax或者来信thinkinjavax@163.com探讨方案。


>是以JSP做表现层不如动态语言(PHP、ASP)简单,表现力强,导致有点“曲高和寡
我个人观点,这可能是和Java世界流派众多,开源标准各有一套有关,这点导致很多人产生选择困惑,而PHP和ASP都是只有一套标准,容易下手,学会走遍天下。

关于技术表现力,不会说PHP和ASP能做到的,Jsp做不到?
Jsp另外还有MVC模式大棒在后面,如果谁将Java代码写在Jsp中,象PHP和ASP那样混杂,肯定会遭受包括我在内一些人棒喝,这样使用者就会产生畏惧心理,原来自己辛辛苦苦做的东西在设计上一文不值啊。

但是,在PHP中,Html和PHP语法就是混合在一起,有谁大骂这是错误的呢,因为人家本身就是这个种。

所以,这个又回答老问题:是技术"曲高和寡",还是使用技术的人的素质太低?

>大家对Java服务端的“强”和“稳”难以抗拒,却对客户端的“繁”和“弱”望而却步
这是事实啊,Java以前从客户端起步,现在强项就只在服务器段和嵌入式手机等方面,windows客户端桌面无疑无法和顶峰VB和Delphi相比,就象中国彩电CRT已经做到极致,外国制造已经无法竞争,但是外国人会在液晶上重新夺回发言,Java在服务器端占据顶峰是一样的,因为现在将来已经不是桌面时代,而是互联网时代。

我的意思:不强调桌面一定要使用java,可以用VB.Delphi,现在很多报表使用的就是VB/Delphi来实现,可以和后端服务器交互,交互协议基于XML,不一定是Web service,Web service被整合到SOA以后,相信随着处理器提高,性能也会提高,看得出来,很多商业厂家还是将未来压在Web service/SOA这个宝上,我们唯一可以做得只有等待,,等待芯片提升,否则我们还能做什么呢?真得很无奈啊。

[该贴被banq于2007年07月05日 11:28修改过]

>Web service被整合到SOA以后,相信随着处理器提高,性能也会提高,看得出来,很多商业厂家还是将未来压在Web service/SOA这个宝上,我们唯一可以做得只有等待,,等待芯片提升,否则我们还能做什么呢?真得很无奈啊。

WS在理论上的确是个大小通吃的理想方案,可惜现在复杂度和性能还是成问题。彭老大说的很实在。

Java的表示层的这个问题,不是Java本身固有的问题,而是现有Web方式所共有的问题。不能怪Java一个。这个只有等新型客户端出来才能有效解决。

Java表示层弱,不仅仅是WEB方式,C/S的Java application也不怎么样。