看了几天java web开发的东东,简单梳理一下。
- 容器
这是java web开发过程中非常强调的一个概念。顾名思义,在它的内部存放着某些东西,各种java对象,包括所谓的bean等等。java的容器也可以称其为一个 应用服务,或一个框架,用户通过配置指定代码或者说对象、构件存放的路径,以及对象之间的关系、对象和容器直接的关系。这通常有一套标准,例如 javaEE本身的servlet/jsp的规范,或容器本身特定的某些标准,你的配置和代码必须符合这种标准,才能被容器调用使用。标准有很多形 式,xml的配置、java接口的实现、对象的继承、java的标注等等,他们决定了对象如何被容器调用、对象之间的关系、以及对象在容器中的运行状态。
目前作为java web开发最常用的servlet/jsp容器是tomcat,企业应用服务器是jboss。spring框架虽然没有服务器的概念,但是从其包含、组织、调用java组件的特征来看,也可以说是容器了。
回忆.net,虽然没有特别强调容器的概念,但是从程序的流程和组织架构来说,iis就是.net web程序运行的容器了。
- web生命周期
在任何技术平台的web开发中,web的生命周期都是一个核心概念。由于web应用都是基于http协议和b/s模式,所以不论采用何种技术,其生命周期都是类似的。
- 请求与响应:
客户端请求-服务器端运算服务-响应,request->service->response,这个标准的http访问流程存在于任何 一种web开发平台中。流程对应的对象引用和方法也都相似,HttpServletRequest封装http的请求,可以通过该对象获取请求相关的各种 参数,HttpServletResponse封装对客户端的响应,通过该对象可以设置http流的各种响应数 据,HttpServlet.service(HttpServletRequest req, HttpServletResponse res)则实现服务的计算内容,获取请求,再根据程序逻辑设置响应。
- scope:
web程序有其自有的运行环境和上下文,在java web开发中一般称其为scope(page|request|session|application)。
- page 是最小运行环境,一个jsp page即一个servlet类实例,但是page scope并非指这个servlet实例的变量,它的有效范围是该servlet对象和某次http请求的交集,只能在当前请求当前页面有效。
- request 是某次请求范围内有效,即使该请求在服务器端通过forward跨越多个servlet。
- session (HttpSession) 是指某个用户会话的全过程,这是为了弥补无状态的http会话缺陷,通过cookie识别客户端并在服务器端添加状态的机制。
- application (ServletContext) 是指在整个应用(context)范围内有效的程序环境。
在这些scope中,request|session|application都可以通过setAttribute/getAttribute在有效范围内设置获取变量。这是一种常见的代码数据共享方式,不过存在线程安全问题,需要注意考虑并发情况。
- 对象各自的生命周期:
所有的对象都有其各自的生命周期,初始化-运行时-销毁。通常初始化和销毁是由容器控制,运行时会运行程序代码实现逻辑。同时,servlet还提 供监听(listener)和过滤(filter)的机制,使程序能控制对象生命周期更广的范围。当然这些都必须实现指定的接口,并通过xml或标注等容 器认可的方式配置编码,使容器能访问调用。
- 请求与响应:
- jsp标签
标签是web页面的表现中非常常见的技术,最原始的标签就是html模板内的变量替换,估计做web的人人都写过。java web的标签有jsp的标准标签、el、自定义标签,JSTL应该也属于自定义标签,只是后来作为标准发布了。
- 繁杂的标签:
jsp标准的标签实现,我个的感觉有些繁杂。java平台一向以自由著称,但是作为一种技术的标准,内容和实现应该尽量简洁,提供一种标准的实现方式即可,是否采用其它第三方库完全可以由用户自己选择。
jsp的标准标签提供了jsp页面实现的基本功能,它包括基本的页面定义、servlet类程序定义、表达式、包含、异常等等,其他程序逻辑则通过 代码片段来实现。继此之后,大家觉得在一个xml文档里面,java代码片段到处飞,看上去不太美观,因此jstl出来了。通过自定义标签,他试图把所有 标准标签实现不了必须依靠代码片段实现的东西转换为标签,从而在jsp模板里消灭java代码片段。因此他实现了环境变量的设置和引用,异常,程序流转逻 辑等等,甚至通过sql库实现数据库操作。我考虑了很久,除非那种没有任何性能要求,简单到只有1、2个的页面的应用,否则是不太可能采用这种方式来实现 数据库操作的。而xml形式的程序逻辑标签(if|else|choose|when…)也过于繁琐,远不如代码片段简洁。
I18N库倒是很简单实用,但是它的本地化文件数据格式太简单,只适合某些很简单的单词单句的本地化,如果有比较复杂的内容,估计这么简单的数据格式是无法满足要求的。不知道有没有接口可以对底层进行重写,否则实用价值有限。
- el库:
el是非常简洁漂亮的,基本上可以把他当作是某种脚本变量的引用,据说javaEE5以后官方也大力提倡使用。但是我觉得也挺逗,这不就和当初试图 消灭jsp模板里面非xml风格元素的目标相冲突吗?el可完全不是xml风格,虽然他比java代码对文档的破坏性小,但他也仅仅是表达式,无法实现其 他逻辑功能。
- 自定义标签:
通过tag api,或者通过简单的标签文件,用户可以创建自定义标签,这和asp.net中的自定义控件和用户控件如出一辙。在我以往的经验中,除了基于学习的目的,从来没有自己开发过控件,用户控件一般也只用于进行简单的包含,方便做缓存或部分逻辑控制。
我感觉自定义标签和asp.net自定义控件的情况类似,多用于某些企业系统的开发,或者是某些商业库的实现。而在一般网站系统中去开发和自定义一 套标签库是非常困难的,代价成本非常高。实现本身比较复杂,增加了开发人员学习成本,库的维护和发展得不到保障,增大了程序复杂度增大了运算资源的消耗。 上面这些问题对于需求变化快、应用访问量非常高的网站应用来说是致命的,而对于一般的企业系统来讲影响比较小。
- 代码和界面分离的传说:
我相信所有做web的人——无论前端后端——都听过这么一个论述,如果web页面模板能够和后端程序完全分离,那么前端和后端能完全相互无干扰的工 作,将大大提高工作效率。从理论上来说,如果能做到这一点确实能大大提高工作效率,然而能做到吗?所谓界面本身就是程序的一部分,他和程序逻辑是息息相关 的。除非某个界面和程序完全没有关系,否则他必然存在某种形式的程序逻辑控制代码,不管这种代码是代码片段、xml还是简单表达式,又或者未来发明个别的 什么东西。这是应用的需求和软件开发工作的实质决定的。
又有某种说法,认为将程序控制实现为html格式类似的标签,可以帮助前端人员更容易识别和修改html模板,这个说法更不可信。我长期和设计师及 前端人员合作,事实上除极个别极端情况,大多数人都很容易理解简单的程序语法,如变量或对象声明、简单的程序逻辑控制等。甚至很多设计师为了页面控制方 便,自己写一些简单控制逻辑。这个学习成本很低,而且基本上所有的流行程序语言语法都类似。而仅jsp的标签库就有多少种?其表达形式何其花样百出?很多 时候还存在需要设计师理解标签库设置界面外观等等情况,对设计师来说复杂度远远高于去了解一门程序语言的简单语法。
对标签这种形式,我的态度是实现方式越简单,表现形式越简洁越好,不必完全拒绝程序代码,不要过于苛求xml文档化,过犹不及。对于jsp标签的现 状,我觉得可以参考asp.net,通过继承或者实现分部类,把jsp的大部分代码逻辑放到后端java程序中去,分离代码和模板。或者强化el,有限制 的实现某种jsp中的脚本语言,甚至嫁接一个别的脚本语言进来。嗯,都不错。
- 繁杂的标签:
- bean就是组件
在我未接触java之前,就总是听说javaBean和ejb,我不知道为什么要取名为bean,那应该只是源于java的某种趣味的称呼吧。 bean就是对象,没有什么不同,只是他需要符合某些标准,以方便jsp或其他调用。看了这些标准,bean和.net中的组件是一个概念,没有什么区 别。在jsp中访问bean很简单,就是一些现成的标签,设置一下bean的scope。我仍然觉得这种标签访问方式感觉很恶劣……
关于ejb,我看的这本书 简单讲了 一个例子,如何创建并访问。ejb我感觉和bean的差别在2个方面,一是ejb是分布式组件,除业务逻辑类本身外,还需要按标准创建相关的接口、配置、 部署,最后提供远程调用的能力。二是ejb的服务器应该会提供强大的管理功能,组件之间的关系、结构组合、性能优化、事务等等,这一部分我看的书没有提。 我看的书还是ejb2的例子,ejb3据说已经大大简化了,嗯,待学习了。
- 有趣的java
搞java也一个多星期了,感觉java确实很繁杂,不论语法还是平台框架,很多东西不如.net平台简洁有效。但是java更加自由,整个开源世 界存在很多框架、技术可供你自由选择——当然这种选择是需要成本的,有时候这也是一种痛苦。另外,对于软件构架,java更趋向于从技术和程序的角度, 而.net趋向于从用户的角度,对于技术人员来讲,java的这种视角更加可贵。