关于JSP的思考

最新推荐文章于 2024-05-15 03:27:12 发布

cuiswing

最新推荐文章于 2024-05-15 03:27:12 发布

阅读量6.1k

点赞数 3

分类专栏： JavaWeb 文章标签： jsp 表现层技术

本文链接：https://blog.csdn.net/u010947191/article/details/51457850

版权

JavaWeb 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

对jsp技术的思考:

今天开始做.net系统到java平台的重写，发现了写jsp页面挺烦的和aspx一样烦，回来了一晚上就在考虑这个问题。

jsp到底还有没有需要?jsp过时了吗?

jsp是页面展示层的一种技术,jsp也是一个servlet,jsp页面的所有内容均会变成servlet中的内容被response一句一句的输出给客户端。以前是要在jsp中直接书写逻辑，所以用到了jsp脚本等java代码，后来觉得不好看，所以改进了，使用el和jstl标签来控制逻辑，来看这样一段jsp的代码：

<html …> <body>
 <div style="padding-top: 50px;">
   <jsp:include page="../menu.jspx"/>
   <c:choose>
     <c:when test="${empty users}">
       Table is empty.
     </c:when>
     <c:otherwise>
      <table>
       <thead>
         <tr>
          <th> First Name </th>
          <th> Last name </th>
         </tr>
        </thead>
        <tbody>
        <c:forEach var="user" items="${users}">
        <tr>
          <td> <c:out value="${user.firstName}"/> </td>
          <td> <c:out value="${user.lastName}"/> </td>
        </tr>
        </c:forEach>
       </tbody>
     </table>
    </c:otherwise>
   </c:choose>
   <jsp:include page="../footer.jspx"/>
  </div>
 </body>
</html>

你觉得这其中的标签比jsp脚本好多少吗？反正我是不觉得的，把jsp脚本换成el和jstl标签时说好处是：前端看不懂jsp脚本，所以换了，我在想：难道这样的标签比jsp脚本好多少吗？这样就更容易理解了吗？反正我没觉得，反而觉得后台得多学这些东西，明明是可以用其他技术代替的东西。当然，可能是我现在层次不够，不能理解其中的美。
网上看到的观点：可以使用 XML+AJAX 代替服务器数据解析后的结果发送到客户端让客户端完成对XML数据的描述,从而对数据和视图更加好的分离,在开发的时候前端开发人员和后台开发人员约定好XML报文格式,就可以同步的开发网站,后期维护网站也比较清晰,只需要修改其中一个点即可,而且页面显示的样式可以多样化.即前台和后台分离完全。
其实我也觉得挺不错的，页面完全和后台程序分离，这样不仅可以同时开发，而且后台就不用再写jsp了，他们不用再关注页面怎么展示，数据怎么填充，他们所需做的就是将发送数据的接口写好。这样前端虽然多了点工作量，但是他们本来不就是要写js的吗，再多写点将数据也展示出来有多大问题呢？关键是这样效率的提高，整体工作效率的提高而不在乎前端后端个别方面的得失。而且这样职责更清晰了，出问题了可以更快定位到负责人。而且后台开发这样的一个接口就够了，对于不同的客户端：android、ios……都可以使用这同一个接口，而不用再单独考虑，这是效率的另一个方面。这是将前台和后台完全彻底的分离了，也符合MVC的设计模式：就是分离隔层，减少耦合。这样所有的人都有个统一的认识：后台提供数据，前台展示数据。就算到时候后台也要做前台的工作，那让他再去学点简单的前端技术就行了，而不是目前的认识混乱，这就是以共识创造效率。
这样的前台和后台完全分离之后，jsp就无所谓了，无所谓jsp、asp、php，，他们都是指一种视图的表现形式，后台的接口都是统一的。
再来回顾jsp的发展史，以前是用servlet技术直接在代码中输出html，那样实在太难受了，所以要想办法改一下，结果只是把servlet改了一下编写方式，就成了jsp，实质上还是一个servlet（jsp会被相应的引擎翻译成servlet），只是把以前的在代码中写html变成了在html中写java代码。在一个jsp中完成从数据库提取数据再展现它。不可避免会造成代码逻层次混乱,所以出现了struct 等mvc框架,为了抽象数据层出现了ORM框架,来完成对应用程序的分层,而如果使用jsp完成对bean的展现就会在html 中夹杂 java代码对后期维护和调试代码都是不方便的。既然想到了Struts、orm等框架，那么为什么不再彻底一点呢？为什么不将数据与html完全分离开呢？用xml/json代替bean到jsp展现数据,而直接使用xml发送到客户机,依靠客户机强大的js库完成展现，或者客户机没有js库也没关系（手机端或者其他终端），只要事先定义好统一的数据格式，不管是xml还是json还是以后会出现的新格式，用其他的技术也是可以读取我从后台发送过来的数据啊。这样子一张html页面就是纯粹的 js+html+css 页面,这应该对页面设计人员有很多便利的地方。
说到手机，又得考虑其他问题：数据传输量vs本地数据处理量。前者决定了流量费和传输速度（体验），后者决定了电池寿命。这个就不多说了，也是可以深入考虑的。
反驳观点：但是以云计算的思维来说，所有的数据应该是在云上计算完成后直接发送给客户端的，而不需要客户端很强的计算能力，将来所有的客户机都不需要安装软件，只要一个带浏览器的操作系统就可以了，从浏览器中与服务器连接，让server完成所有的事情后发送给Client结果就行了。这样就与我所考虑的冲突了！怎么办，关键是现在的客户机确实是越做越强大了啊，虽然浏览器也越来越强大，但是其他软件的装机量也在同步上升啊。而且用户也没考虑到这样的情景：让云取代所有的本机功能。因为大家都觉得不靠谱：一个是不安全、二是以目前的网速发展就算再有N多年也不可能达到理想的云计算服务功能，况且还得考虑我国国情在里面。到时候又是国家安全、国企与人民撕逼的时候呢。所以这样看来我的思路还是没错的，让闲置的客户端处理数据以节约资源。
反驳观点：到时候客户机就成了富客户端，随之而来的弊端就是客户端需要有更多的类库来支持。这个我不说话……
再反驳：技术无所谓过时不过时，根据实际项目需求进行技术构架，合适就可以，例如政府项目的特点就是浏览器都是ie6，你非要搞extjs那我就不说到时候会怎么样了。
客户唯一关心的是，东西能不能做出来，对技术选型兴趣不大，如果大家都用JSP，那么客户就会选JSP
所以jsp技术没有过时，这样明确给出结果了：没有过时！
一切都得按照实际的需求来做，按照客户的要求来做。所以如果遇到客户机不允许的情况就得老老实实按着规矩来。
我的这个想法应该是完全可行的，如果自己做，并且也有前端配合的话就可以这个弄了，没有也没关系，了解点简单的原理和技术就可以自己写了，大概当时jsp中数据和展示没有完全分离也是因为当时并没与专业的前端吧，而且也怕前端翘了就没人做了，还是为了节约成本——后台一个人就可以做前后台所有的事？
我就准备在我的项目中这样干了，虽然不完全是这样做，但是可以一点点的来，然后尽量多的替换掉所有的jsp页面，那样我的前端水平是不是也提高了呢~

想到后来，不只是jsp，其他类似的表现层技术如asp不也是这样的吗

看一篇相关的文章：http://spring.io/blog/2012/10/30/spring-mvc-from-jsp-and-tiles-to-thymeleaf/

再看一篇十六年前（2000年）的文章：http://www.ibm.com/developerworks/cn/java/w-friend/

才发现别人早就已经想到了并做了深入的思考呀

有人说要：看淘宝UED的系列文章，看完后可以了解avalon，vue。谁有这方面的资料发给我瞧瞧呗~

再贴一个面试题：

JSP技术主要缺点和优点有哪些?
缺点：
1. JSP技术极大的增加了产品的复杂性.为了获得系统的跨平台功能和产品伸缩能力,java系统开发了多种产品,如,JRE,JDK,J2EE,EJB,JSWDK,JavaBeans ,只有有效地将它们组合在一起,才能产生强大的功能.（部署有难度）
2. java的高效率运行需要占用大量的内存和硬盘空间. 一方面,java的高速运行是通过 .class文件常驻内存来实现的.另一方面,还需要硬盘空间来存储一系列的.java 文件和.class文件以及对应的版本文件.（硬件要求高）
3. JSP程序调试困难.
JSP页面执行时, 首先被转换为 .java文件(Servlet), 然后将.java文件编译为字节码文件. 这样,出错信息实际上指向的是转换后的那个.java文件(Servlet), 而不是JSP本身. （调试有难度）
优点：
1.JSP代码跨平台, 即一次编写,处处运行
众所周知,由于微软的垄断性,它的产品可移植性做得十分差,ASP也不例外,
2.JSP组件跨平台
JSP组件(企业JavaBeans,JavaBeans或定制的JSP标签)都是跨平台可重用的.企业JavaBeans组件可以访问传统的数据库,并能以分布式系统模式工作于Solaris,Linux,UNIX和Windows平台.
3.支持多种网页格式
目前, JSP技术支持的网页格式还没有一个明确的标准.一般来说,JSP技术既可以支持HTML/DHTML的传统浏览器文件格式,又可以支持应用于无线通信设备如移动电话,PDA等设备进行网页预览的WML文件格式,还可以支持其他一些B2B电子商务网站应用的XML格式.
4.JSP标签可扩充性
尽管ASP和JSP都使用标签与脚本技术来制作动态Web网页,JSP技术允许开发者扩展JSP标签,定制JSP标签库,所以网页制作者充分利用与XML兼容的标签技术强大的功能,大大减少对脚本语言的依赖.由于定制标签技术,使网页制作者降低了制作网页的复杂度.
5.健壮性与安全性
由于JSP页面使用的脚本语言是java语言, 因此,它就具有java技术的所有好处, 包括健壮的存储管理和安全性.

来自IT公司面试手册

刚才随手用记事本写的，直接贴上来了，格式有点难看。

--------------------------<hr>---------------------------------

update:2016-7-18

最近做新项目，提供服务使用的都是restful结构的接口，然后今天查了下REST，这不就是之前我所考虑的分离吗？但是比我所想的东西多多了~

copy一段：

首先为什么要用RESTful结构呢？
大家都知道"古代"网页都是前端后端融在一起的，比如之前的PHP，JSP等。在之前的桌面时代问题不大，但是近年来移动互联网的发展，各种类型的Client层出不穷，RESTful可以通过一套统一的接口为 Web，iOS和Android提供服务。另外对于广大平台来说，比如Facebook platform，微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口，于是RESTful更是它们最好的选择。在RESTful架构下：

作者：覃超
链接：https://www.zhihu.com/question/27785028/answer/48096396
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

cuiswing

关注

3
点赞
踩
4

收藏

觉得还不错? 一键收藏
1
评论
关于JSP的思考

对jsp技术的思考:今天开始做.net系统到java平台的重写，发现了写jsp页面挺烦的和aspx一样烦，回来了一晚上就在考虑这个问题。jsp到底还有没有需要?jsp过时了吗?jsp是页面展示层的一种技术,jsp也是一个servlet,jsp页面的所有内容均会变成servlet中的内容被response一句一句的输出给客户端。以前是要在jsp中直接书写逻辑，所以用到了jsp
复制链接

扫一扫

专栏目录