选择jsp而不是servlet作为BS前台主流方案是JAVA的战略性方向错误
原文
许多人认为JSP是JAVA向微软ASP挑战的成功产品，到今天，围绕着JSP方案发展出了TAG/EL等技术，JSP作为JAVA的BS前台界面方案看来已经是无法逆转。但在我看来，JAVA选择JSP这种表达形式，恰恰是它最失败的地方，是对ASP的一种拙劣的模仿，它本来可以做得更好的，甚至可能据此让微软彻底退出服务器领域，但最终，却可能成为足以令JAVA最终失败的重大战略方向性错误。



JAVA到今天仍具有微软所有语言所不具备的优点，就以C#而言，只不过是形似而神不似。java最根本的地方不在于它的OOP，不在于它是C++的语法优化，这些都不重要，而在于它的虚拟机机制，使它成为最佳的跨平台的服务器语言；而C#无论多么语法相似，都无法改变这样一个现实：它只是微软CLI中的语言中的一种，它再成功，也充其量是取代了在windows运行的JAVA；某种程度上，C#是一种注定没有必要存在的语言，在CLI中，只需要一种就够了，象VB.net。
JAVA到软件世界带来的最大的影响是令软件真正出现了分层开发，出现真正的三层结构。尽管有些家伙吹嘘他们的软件是N层结构（真不要脸！），其实究其实则，都只不过是传统的CS式的两层结构的变种，不能把函数每加一个就称为一层噢！JAVA出现体现了软件的创造性思维，但JAVA犯的错误最大的地方就在于他毫无创造性地模仿了ASP，并且，竟然把JSP作为中间件的主要访问手段加以发展。这是一个重大的失误，也许，如果有一天JAVA死掉的话，就死在这个失误上面。

ASP的是模仿最早的livewire式的jsp和cofusion，livewire也是本人最早在项目中接触的jsp，与后来的java jsp毫无相同之处。这种netscape公司的"jsp"与asp有共同的特点，就是完全没有面向对象的特性，是纯粹的解析性脚本语言，后来的PHP也是这样的产品，PHP本质上可以看作是Cscript。这些语言的出现原意是要满足那些不懂计算机语言，从HTML美工转行的半吊子程序员的能力需要，美其名为让美工可以写动态网页程度。不过，这个开发假想成了互联网出现以来最大的笑话之一，美工式的程序员始终不能写真正的动态网页，反而让真正的程序员去做了美工的活了，最典型的产品就是struts。

java与此完全不一样，它是一种需要编译的语言，具有完全的面向对象的能力；所以，它如果能够发挥这种特点，打败其他的几种脚本是毫无困难的。结果，SUN的天才的笨蛋们（我觉得这种称呼最客观，既是天才，也是笨蛋），选择了用坦克车去和捷达争夺出租车市场，做起了JSP。而我认为， servlet才应该是它最佳的发展方向。今天，我已经忘记了当初是什么原因令我放弃了jsp而使用servlet作为项目解决方案的；只记得后来完全放弃jsp是由于兼顾两种形式在传递变量和地址时非常复杂，还不如光用一种。今天当我以为我当初错了，而标签/EL等技术的出现会令JSP不同往昔而再次在重大项目中选用JSP时，（其中一个原因也是那个笑话的延续，希望不懂JAVA的维护人员可以在交货后自已维护系统前台），随着项目的进入，我记起了当初放弃JSP的原因：一个是当时的代码管理非常困难，JSP系统基本上与其他PPP类程序一样是不可维护的；另一个原因就是JSP无法基于模板进行维护。前者由于tag等的出现而缓解了，（从前也可以使用include sevlet的办法达到接近的效果），后者仍然一样，关键就在于不能复盖已有的代码。而在servlet中，重载一个方法是很容易的。

许多人以为servlet难写，在doget/dopost/init/等中需要塞进那么多的方法；其实，这是一种误解，这种误解是没有认识到 servlet本质上是一种java class,可以轻易公有私有的方法，也可以继承，可以重载等等。因此，在servlet中很容易就可以形成一个全系统追随的模板，一改一起改。相反，以为写servlet就是在doget中用out.println输出的，是把写JSP的理解带进了servlet;JSP编译成servlet后，也正是这个样子的。所以它不存在继承的价值。

那么对于复杂的html界面如何达到与jsp同样的简洁嵌入呢？其实很简单。我当时的解决方案是使用${xxx}标记预置默认的方式，然后把这些带有大量html代码的标记的文件存在某个目录；在sverlt初始化时通过文件字节流读入，使用一个字符串分析的组件（今天还在用呢）把标记转化为相应的实际动态变量。这恰恰就是今天的号称最先进的EL 表达式语言的解决方法。真的，我一点都不觉得有写servlet比一般的网页程序难在什么地方。某种程度上，我觉得自已做了一个jsp解释引擎出来了。

那么这种土产的jsp和真正的jsp有什么区别呢？最大的区别就在于它是把jspp仅仅看成是为servlet服务的html代码库，而不是 serlvet为jsp服务。换言之，这里的jsp是类似于今天的tile/Jspfragment的东西。一个小小的差别，带来的效果完全不一样，因为它可以完整的发挥出java面向对象和继承的特点；甚至可以象PB那样将整个项目前台作为一个类"继承"出来，再扩展和重整需要修改的地方。而这种能力，是那些"P"语言永远不可能做到的。但是，SUN偏偏跟在微软屁股后面去拙劣地模仿JSP。


不妨回顾一下在BS前台最常见到的架构是什么? 是一个大的网站上大部分版面具有类似的框架布局，每个分栏中只有其中某处不一样。JSP可以很容易地共用其中一样的部分；但对于其中不一样的部分就无能为力。由于JSP不能形成顶级模板，而每一个大分栏中部内容不一样，所以唯一的办法就是每一个大分栏拷贝出一个jsp文件来获得一个顶级框架模板；显然，这意味着对每一个文件的相同框架部分进行维护；项目越大，这样日后更改的工作量越大。这时侯真的有点怀念servlet的功能了，对这种需求，只需要写好一个 servlet,其他的servlet继承它，然后重载它的中央内容方法，就搞惦了。当前要达到类似要求的唯一办法，似乎只能是在顶级页面中使用if-else/equal-notequal判断里include不同的内容文件。舍此，还有什么好办法吗？

JAVA的BS前台的正确的思路应该是以一个可以订制继承方法的servlet为核心，然后可以分解一些象jsp这样的文件，类似今天的jsp中技术都可以用到这些JSP文件中。也就是说，核心应该是一个可以定制的servlet，而不是提供一个工具，把jsp编译成不可变的servlet。顶级文件应该是servlet，而不应该是JSP，这就是我所说的。


我一个人是不可能与整个JSP社区作对的，不可能一个人完成SUN几千个开发工程师的工作，既然SUN的某个天才大笨蛋选择了JSP作为JAVA在 BS的表达主流，到今天，如果我仍使用JAVA作为前台界面程序的话，最好就是随大流标准，而在几年前，JSP完全不是标准，情况是不一样了。不过，从今天实际的体验来说，我仍然强烈地觉得，SUN犯了一个严重的方法性错误。更为遗憾的是，SUN没有做到的事情，让微软在ASP.net中有所体现了，所幸微软的东西从来不打算跨平台移植的，所以SUN还有一点机会。
[点击此处收藏本文]
发表于 2005年03月30日 8:09 AM


zyx 发表于2005-03-30 10:05 PM
正好看到本文，有些不同的想法想与原作者分享。
我觉得你是在想尽办法去弥补Servlet的先天不足，却没想过多多利用JSP的优点。如果以JSP为出发点来解决问题也许比从Servlet出发容易得多。MVC是多么经典的架构，View必须独立出来，JSP就是一种独立View的形式。当然，你说的也不失为一种办法，但我确实觉得，他们在本质上是一样的，如果硬要说有什么不同的话，那只能说，JSP更直观，更符合人们的一般思维。之所以这么说，因为它们达到的目的是一样的，为什么不使用成形的技术而一定要另起炉灶呢？而关于面向对象、继承，我觉得也没有什么说服力——你为什么要想办法去继承一个界面呢？界面已经是独立的东西了，你可以在你希望的任何地方使用它，而不是去继承它。关于组合与继承谁优谁劣的问题我想没有必要再讨论了，网上这方面的讨论一抓一大把，原则就是，能组合的场合，绝对不要继承!
关于最后那个BS架构问题，我想你可以把结构相同的地方include进来，而不是以相同的东西为基础include不同的部分。这点从Asp.net的Web用户控件思想也可以得到启发。
这些就是我的一点看法，如果有言语不当之处还请见谅。我只是一个还没毕业的在校大学生，做过一些小型项目，经验还很欠缺，也许有很多我没有考虑到的东西，还请作者提出大家讨论
我的QQ:14919012/MSN:westxx@hotmail.com


版主 发表于2005-03-31 12:07 AM
"关于组合与继承谁优谁劣的问题我想没有必要再讨论了，网上这方面的讨论一抓一大把，原则就是，能组合的场合，绝对不要继承! "

这段话是错误的。错就错在没有分清楚对象和组件的区别。
对象就一定是要继承的，而组件，是组合的。MS的东西的对象就是框架对象，本身与组件非常接近。但JAVA的对角是抽象的客观对象，因此，两者是不一样的。在MS的思维方式下，就会出现如上面这样的基本概念混淆。

如果是jspBS，架色，关键在于网站的基本组件建立在什么层次，目的都是为了可重用和可维护。include和被include是随机发生，时而这个更好时而那个更好，不一而尽。servelt也是可以include的，同时它提供了基于顶级模板的客理能力，看来你其实并不理解MVC。全文的意思是批评SUN不顾自已的技术特点，向老的ASP习惯模仿。而与MVC无关。

在BS环境中MVC在什么程度上是有利的，也是很有争议的。可以肯定，你的教科书说的东西，基本上都可以认为是过时的，过分结论化的。




版主 发表于2005-03-31 12:10 AM
另：
对象真正的争议，也包过对过程化goto的否定，不是继承和组合的问题。而是多重继承/goto，和接口两种模式选用的问题。


zyx 发表于2005-03-31 10:51 AM
我想可能我没有表达清楚，我提MVC的意思是说MVC要求视图应该独立出来，现在什么所谓三层架构也有这个要求，这点我想没有问题吧？(或者说多数情况下它应该是正确的？)但Servlet处理这个问题你真的觉得方便吗？BS中的视图本来就是由HTML主要负责的，不管是用作者的方法，还是JSP，可以肯定的是，视图部分是一个整体，不应该是面包片。既然如此，放到了Servlet里有什么实质性的好处呢？可重用，可维护？能不能具体一点，放在这时有什么功能是放在JSP里做不到或是困难的？我觉得文章里的那一条还说明不了问题。
关于继承和组合的问题或许我有些绝对，这个先不讨论，不然又该长篇大论了。
另外说明一下，现在大学的教科书也许比你想象的还要差，我的看法并不是来自那里。


jcx 发表于2005-03-31 3:46 PM
作者写这篇文章带有很强的个人想法，没有什么说服力，缺乏根本的事实依据。你说SUN人是天才大笨蛋，带有一定的人身攻击！感觉作者还没有长大，胡言乱语在这里发了一通的牢骚！


zwwwxy 发表于2005-03-31 8:37 PM
或者应该看看真实的网站程序是怎么写的。估计你的感觉是一大篇html文件，然后把其实的一部分用<%%>换成javalet的输出，这是一般人的理解，的确，简单的jsp是这样写的。也的确，在这时侯要比写出out.println要容易。问题在于，在做大型网站时，是不会按html基础修改，然后简化成若干最简单的html，通过循环输出动态内容。所以这个时侯，是否写几个out.printlln与直播妆<%%>没有大的区别。相反，<%%>中反而不便掌握页面程序的流程。

这是一个实例，真正写过jsp程序的人都有这个感觉。换言之，在大型的网站，象sun自已的网站，它其实是一个个的片片，sun取名叫fragment组成的。那么作为一个整个程序比分散程序有什么好处呢？因为它提供了一个上下文的空间；可以存放各种必须的变量，象访问控制等。

如果两者是不可兼得的，那么也就没有什么好争的，各人按自已的需要各取所需就可以了；但如果是可以兼得的，为什么不这样做，而去刻意模仿asp呢？



回jcx这种网友 发表于2005-03-31 8:52 PM
"作者写这篇文章带有很强的个人想法，没有什么说服力，缺乏根本的事实依据。你说SUN人是天才大笨蛋，带有一定的人身攻击！感觉作者还没有长大，胡言乱语在这里发了一通的牢骚！"

这算什么话？？看来中国人是不应该有自已的想法的？有没有说服力就看各人的看法了，作者并没有义务要说服你！事实根据？作者写了五十万行的java程序，开发了上千万的软件项目产品，大概只会比你多不会比你少，你自已对作者人身攻击时的事实根据有没有作者提出来的百分之一？有根有据三千多字，说是没有根据的攻击，你区区20个字反而是好好商量？

所以有时侯对一些中国同胞的传统陋习真是又好气又可笑：仿佛永远是不出声的笨蛋才令让他满意似的。典型的奴性思维。 就算是“天才的大笨蛋”，也不是一句攻击话，SUN的麦克利尼就是这样称盖茨的。

好好讨论就好好回答，换了别人，大概会眼也不眨就删掉了这种无礼回贴。不过作者本着共论的游戏规则，言论自由，是不会这样做，以后也不会再理这种自相攻击，中国人自已相轻的无聊贴的



zyx 发表于2005-04-01 11:05 AM
或许我没有做过这么大的项目，随便翻了几页sun的网站也没有找到你说的那种编排方式。我还是不同意把页面切成小片放到Servlet中，这么做有些得不偿失了，后期的维护怎么办？这会给你带来很大的麻烦，这点我想你比我更清楚。另外下文的好处我没明白，我们还有session，有request，甚至applications


zwwwxy 发表于2005-04-01 8:44 PM
所有这一切都是为了维护的方便，或者你还没有体会。不过，从你的文字中可以看出，这是对网站方式的认识不同。换言之，网站是网页（花样）驱动的，还是内容服务驱动的。如果是前者，中国的网站，也许包括你的作业，都是这样的方式，体现为大量的多变的网页；这时抽象出模块是困难的，从事纯粹的HTML抽取动态内容的JSP是合适的。但对于大型内容服务驱动型的网站来说，网页一般是简单的，而后台要求是复杂的。这时侯前台抽出取可重用框架是可行的，也是高效的。这是国外大型网站的特点。SUN是不是这样说的我没有注意，事实上SUN对于JSP的编程模式并没有太多的涉及,事实上，SUN已经把JSP/servlet的发展完全下放到jakarta社区，包括投入自已的核心工程师；因此apache/jakarta社区就在大量这样的介绍，包括它的相关项目，象struts,tiles,velocity,slide,taglib等都是这种类型。当你觉得我是另想办法弥补servlet的不足时，我却觉得是在用其他办法弥补jsp的不足，目的就是你所不认同的，事实上是对页面最终对象的抽象过程，通过谋求可重用性可维护性降低开发成本。

大概你以为写servlet后需要象jsp一样改。其实，servlet只是一个框架，要良好使用servlet，就应该做到在外面配置。我们要的只是servlet的严谨框架，并不是要他一行行输出。
至于说到上下文，我已经举出一个例子，象一个对每个页面进行访问控制，同时是按组配备权限的应用时，无论是application,request,sessions都是不合适或不够的，因为，这时侯页面本身是控制对象。至于说继承有没有用，你还是试试再说吧。

目前的经典做法，包括我处自已，都是使用servlet和作为顶级控制框架，然后通过xml中提供html模块，servlet解释这些模块并替换变量，最后输出网页。反过来的方法也差不多：使用jsp，通过标签/servlet/shtml输出动态内容。

这些都是经典的做法，非此即彼，至于说按用户要求随动生成网页的xSP开发模式，我们称之为应召式的开发，项目到一定阶段就会因为页面散乱而无法维护，成本会直线上升的；事实上如此诱发的需求变迁，会令项目永远做不完。如此，倒不如一开始用php/asp,又何必用jsp呢？

讲到底，实距出真知，就不要做事先从本本上搞学院式的争辨，看完东西亲自做一做体会一下各种方式的优劣,才能真正消化对方的技术优缺点。这是忠告。



zwwwxy 发表于2005-04-02 8:21 AM
<a href="http://blog.csdn.net/zwwwxy/archive/2005/04/02/334958.aspx">参看归纳性回答</a>

CSDN的系统是怎么做的？速度如此慢，十次至少九次半不能访问。估计是ASP.net，加SQLSERVER，把内容放在数据库中，如果是这样，就不奇怪了。它的流量在博客中并不算大，如此表现，作为一个专业的软件技术博客，也实在太丢人了。


coreday 发表于2005-04-05 10:08 AM
跟贴的两位象是捧着书本，以为学会asp/jsp就无所不能的菜鸟，稍知皮毛就拿着本本争第一，一点不愿意深入了解


zwwwxy 发表于2005-04-09 10:07 PM
这几天系统好象快了不少