当前位置导航:炫浪网>>网络学院>>编程开发>>JAVA教程>>J2EE

初学者:如何选择Java企业系统架构

    现在Java领域各种技术百花齐放,名目繁多,如何根据自己的需求选择这些框架呢?特别对于初学者,在学习选择方向上也非常迷茫,如何有针对性的根据自己项目特点进行学习就变的更加重要。

    下面我们从一个发展角度来对J2EE/Java EE的这些框架诞生进行一番考量,可能对我们的选择有很大帮助。

    首先我们需要明白一个高质量的J2EE系统是什么样子?高质量的J2EE/Java EE系统标准实际就是OO设计的标准,松耦合是OO设计的主要追求目标之一,那么无疑解耦性成为衡量J2EE/JEE质量的首要标准。实际选择中,还需要兼顾可伸缩性/性能/开发效率等方面综合考虑。

    J2EE/Java EE号称多层结构,为什么多层比两层好?因为多层结构解耦性好,带来维护拓展方便灵活。

    典型的J2EE/Java EE至少划分三个层次:表现层/业务逻辑组件层/持久层。

    表现层英文是Presentation Layer,是实现显示功能的,这部分一般使用B/S结构来完成,当然你也可以使用专门远程客户端来实现;

    业务逻辑层因为是由大量组件(Components)组成的,也可称为组件层,组件从不同角度又可分为各种类型,然后又有不同的流派,目前占主要位置的是Model+Service,模型加服务,所以这一层又称为业务服务层Business Service;也有称为Model业务层;

    持久层是负责对象持久化也就是数据库操作的层次,英文Persistence Layer。

    SUN伙伴们推出J2EE标准时,分别对这三个层次规定了标准实现,表现层使用Jsp/Servlet技术;业务组件层使用EJB的会话Bean;持久层使用实体Bean。同时,标准将业务层和持久层在物理上组成一个新的容器EJB容器,与表现层技术完全一样的容器,这样,J2EE技术被细化为Web和EJB,物理上有Web容器和Web应用程序;以及EJB容器和EJB应用程序。

    当然,J2EE/JEE的发展不止这些,这三个层次技术分别独立发展,高歌猛进,下面分别单独陈述,当你了解某种框架技术为什么诞生时,你可能就知道你该在什么情况下选择它们了,工具总是因目的而生!

    表现层框架

    J2EE/Java EE虽是多层结构,但它不是一种强制性多层结构,也就是说,你也可能做成传统两层结构,有的初学者直接使用Jsp嵌入Java代码调用数据库这样结构实际不是多层结构,还是以前的两层结构。

    在Jsp中嵌入大量代码,一旦报空指针错误就很难找出问题,很多初学者下载JiveJdon 2.5后就经常碰到这个问题,因此大量有关空指针错误问题出现论坛里,为什么他们不能自己解决呢? 那是因为无法定位错误在Jsp中的位置,Tomcat等服务器只告诉我们错误在index_jsp.java(Jsp的java文件)位置,搞得一些人经常会跑到Tomcat服务器内部翻找Jsp的Java文件,这一过程无比痛苦(为了减少初学者这种痛苦,本站暂停了JiveJdon2.5的下载)。

    J2EE/Java EE的发展就是降低这种痛苦,首先想到的方式是:在Jsp调试上下苦功,要求Tomcat等服务器提供详细的错误定位;可惜到Tomcat 5.5我们也没看到这种功能;实际上,根本解决之道就是将Jsp的调试变成java组件的调试。

    首先通过MVC模式规定Jsp只能等同于Html,不能包含Java代码,将Jsp和Java代码分离,可是这样分离之后,它们结合起来又麻烦了,所以,虽然你使用MVC模式,但是还是直接基于Jsp技术,带来的是开发效率的降低。

    Struts框架解决了这个问题,通过ActionForm可以将Jsp和JavaBeans方便快速地结合起来,但是有人又抱怨Struts的ActionForm限制太死,与Jsp虽能对应,只能一个ActionForm一个表单对应,而不能任意组件JavaBeans都可以和Jsp任意字段对应,这时就出来了组件型框架JSF/Tapestry。

    表现层框架Struts/Tapestry/JSF架构比较

    业务逻辑层框架

    可伸缩性

    因为EJB标准的推出,业务组件层以前基本是EJB的天下,但是EJB功能实在太强大,它考虑了世界顶级大型系统需求,因此免不了显得很复杂,当初,基本上所有的大型企业高端都是选用J2EE,选用J2EE实际是选用EJB。EJB强调的高可伸缩性为大型企业日益发展提供最大的发展空间,不再因为企业快速发展导致整个企业系统结构都要发生根本变化,这是使用EJB的现实优势。

    这种企业系统的可伸缩性不是因为EJB存在才显得重要,而是我们企业架构选择需要考量的基本因素。换句话说,无论我们使用EJB与否,这个问题都需要考虑:一台服务器不够用怎么办?如果这台服务器死机会对企业运营带来什么影响?如果每个星期这台服务器停机维护升级会不会对企业带来打击?我的企业系统是不是需要可靠的、几乎不当机的7x24运行?当企业系统面对大量外部访问用户时,一台服务器是否够用?多台服务器联动的需求是否涉及软件技术更换?

    在这个现实因素考量后,如果觉得不是很重要,或者说将来一段时间内这些因素无所谓,那么可以不选用EJB了。

    为什么有不选用EJB的理由?因为它复杂,学习起来比较困难,EJB帮助我们考虑企业中可能碰到的大部分问题,实际上,有的我们不需要,这也就是为什么说EJB是一个重量级解决方案所在。

    与重量级相比的是轻量,业务组件层轻量级解决方案有Spring/HiveMidn/Jdon Framework等,轻量一词曾经因为EJB的出现而变得时髦,给人造成的感觉是:EJB花了老鼻子力气完成的那些功能,使用我轻量级解决方案可以轻而易举也能解决,举重若轻啊,其实这是一种误解。

    当曾经以轻量自居的Spring将事务机制纳入自己怀抱中时,它也开始低调轻量了,实际是不轻不重了;当然如果它把分布式计算和事务再次加入时,天平砝码也会沉下去的。

    初学者总是愿意使用简单的解决方案,学习使用方便,因此比较喜欢轻量级框架技术,这是正常的,但是在使用轻量级别框架之前必须明白:你的系统将来真的只需要一台服务器即可?你的项目完成期真的非常紧急?

    如果只需要一台巨强服务器,就不必选择EJB,EJB是因分布式多服务器而生,对于单台服务器,缺乏本地透明性,也就是说:你无法透过EJB直接和本地JVM或文件系统等打交道,透明性也是衡量一个框架的重要指标。

    当然,重量和轻量并不完全对立,EJB3就是为了简化J2EE的使用,使得EJB不只是擅长处理大型企业系统,中小型系统也使用很方便,这实际上也是EJB轻量化的一种努力。什么是Java EE 5?

    所以,对于架构选择来说,根本前提是需要明白你的系统现在或将来一段时间(注意需要考虑将来一段时间,不能只看眼前)是中小型系统还是大型系统?

共3页 首页 上一页 1 2 3 下一页 尾页 跳转到
相关内容
赞助商链接