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

07-07-02 lgx522
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修改过]

              

banq
2007-07-03 16:28
>我们所需要的,应当是简单的表示层。换言之,至少不能比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

lgx522
2007-07-03 18:02
这篇帖有两个议题:

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

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

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

gougou3250
2007-07-04 18:00
java的web应用很难么 没感觉

<%%>全部用JSTL标签来替代

然后跳转,简单逻辑等部分由struts来负责 struts2.0相当简单好用

如果有一定的技术积累,可以用JS 来开发WEB组件 通过拖拖画画的方式就可以构建页面了, 整个HTML BODY就是一个大DIV 在上面想加什么就加什么

象DOJU DWR等等 已经出现很多这样的框架 只是功能都很有限 只是一些最简单的应用

lgx522
2007-07-04 18:06
Struts2.0有点慢,时常还蹦出点小Bug,感觉不如原版Webwork。

猜你喜欢
2Go 1 2 下一页