javaEE规范和SSH三大框架到底有什么关系

从1994年到2004年间,互联网技术经历了快速发展,网景公司的Navigator浏览器开启了网页互动的新时代。Sun公司的Java语言及J2EE平台在此期间发挥了重要作用,但随着互联网泡沫的破灭和技术的不断演进,Spring、Hibernate等框架应运而生,解决了J2EE存在的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1994-2000 年是互联网的大航海时代。

请注意,下面的时间点及其重要。

1994年,网景公司(Netscape)发布了Navigator浏览器0.9版。这是历史上第一个比较成熟的网络浏览器,轰动一时。但是,这个版本的浏览器只能用来浏览,不具备与访问者互动的能力。网景公司急需一种网页脚本语言,使得浏览器可以与网页互动。

1995Sun公司将Oak语言改名为Java,正式向市场推出。Sun公司大肆宣传,许诺这种语言可以"一次编写,到处运行"(Write Once, Run Anywhere),它看上去很可能成为未来的主宰。

1995年5月,网景公司做出决策,未来的网页脚本语言必须"看上去与Java足够相似",但是比Java简单,使得非专业的网页作者也能很快上手,于是javaScript就诞生了。

1998Sun公司在发表JDK1.2版本的时候,使用了新名称Java 2 Platform,即“Java2平台”,修改后的JDK称为Java 2 Platform Software Develping Kit,即J2SDK。

并分为标准版(Standard Edition,J2SE), 企业版(Enterprise Edition,J2EE),微型版(MicroEdition,J2ME)。J2EE便由此诞生

 

sun设计J2EE的初衷正是为了解决两层模式(client/server)的弊端。

在传统模式中,客户端担当了过多的角色而显得臃肿,在这种模式中,第一次部署的时候比较容易,但难于升级或改进,可伸展性也不理想,而且经常基于某种专有的协议,通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。

 

J2EE将网站的开发分为四层:

 

客户层组件

J2EE应用程序可以是基于web方式的(浏览器),也可以是基于传统方式的.浏览器方面主要推动了html+css+js

 

web 层组件

J2EE web层组件可以是JSP 页面或Servlets.

 

业务层组件

EJB做了业务逻辑的处理和数据库相关的操作。

有三种企业级的bean: 会话(session) beans,实体(entity) beans,和消息驱动(message-driven)

beans. 会话bean 表示与客户端程序的临时交互.实体bean 表示数据库的表中一行永久的记录. 当客户端程序中止或服务器关闭时,就会有潜在的服务保证实体bean 的数据得以保存.消息驱动 bean 结合了会话bean 和 JMS的消息监听器的特性,允许一个业务层组件异步接收JMS 消息.

 

企业信息系统层

存储信息。企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划

(ERP),大型机事务处理,数据库系统,和其它的遗留信息系统。

 

这套规范大大降低了网站的开发难度,从某些方面看它绝对是成功的。可网站的开发还是比较困难。J2EE这套规范应该是订的太早了,因为当制定这套规范时互联网正在迅猛发展,可以用一日千里形容。

2000年发生互联网泡沫,sun公司一蹶不振。同时遇难的还有一堆不知名的小互联网公司。可能是那时候做网站的一堆人们日子比较清闲,毕竟很多公司都关门大吉了。有些人就发现,J2EE这套规范臃肿、低效、难用且脱离现实。于是他们下定决心,对其改造。

 

2000~2001年 Craig觉得web层可以使用MVC框架使该层开发更加容易,于是就有了Struts,这一步是对原来规范的很好实现,并没有产生质的突破。

 

2001~2003年 Gavin 觉得EJB连接数据的部分有待改进,于是就有了Hibernate,Hibernate并没有被规范束缚,而是想怎么改就怎么改。

 

2002年左右 html+css+js也开始渐渐分离

2002~2004年 Rod觉得类和类之间的依赖关系应该改善,于是就有了Spring,Spring是为了让javaEE规范更加易用,因此对其进行了大刀阔斧的改造。在当时看绝对是取其精华,去其糟粕。

 

 

从1998年到2004年,sun公司不可能没有发现J2EE存在的问题,可是从2000年以后sun就无能为力了,因为它的股票一落千丈,跌的就剩下零头了。这才有了SSH这些框架诞生的时间和空间。

由此看来危机恰恰才是我们的转机,在黑暗中看到希望,我们的成就才能超出我们的想象。

.Hibernate<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序实用,也可以在Servlet/JSP的Web应用中使用,最具革命意义的是,Hibernate可以在应用EJB的J2EE架构中 取代CMP,完成数据持久化的重任。 多数开发机构经常采取创建各自独立的数据持久层。一旦底层的数据结构发生改变,那么修改应用的其余部分使之适应这种改变的代价将是十分巨的。Hibernate适时的填补了 这一空白,它为Java应用提供了一个易用的、高效率的对象关系映射框架。hibernate是个轻量级的持久性框架,功能却非常丰富。 优点: a.Hibernate 使用 Java 反射机制而不是字节码增强程序来实现透明性。 b.Hibernate 的性能非常好,因为它是个轻量级框架。映射的灵活性很出色。 c.它支持各种关系数据库,从一对一到多对多的各种复杂关系。 缺点:它限制您所使用的对象模型。(例如,一个持久性类不能映射到多个表)其独有的界面可怜的市场份额也让人不安,尽管如此,Hibernate 还是以其强的发展动力减轻了 这些风险。其他的开源持久性框架也有一些,不过都没有 Hibernate 这样有市场冲击力。 面回贴情绪有点激动,希望谅解,我不是因为有人批评Hibernate而感到不快,而是因为帖子里面的观点实在让我觉得荒谬。不管觉得Hibernate好也吧,不好也吧,我唯一觉得 遗憾的是,在中文论坛里面找不到一个对Hibernate的真正高水平的评价。在TSS上有一个关于Hibernate的hot thread,跟了几百贴,其中包括Hibernate作者GavinLiDO JDO的 CTO,对于JDOHibernate有过一些激烈的争论,我曾经耐心的看了一遍,仍然没有发现针对Hibernate真正有力的攻击,那些所谓的攻击无非针对Hibernate没有一个GUI的配置工 具,没有商业公司支持,没有标准化等等这些站不住脚的理由。 补充几点我的意见: 一、Hibernate是JDBC的轻量级的对象封装,它是一个独立的对象持久层框架App Server,EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合,例如Java 应用程序的数据库访问代码,DAO接口的实现类,甚至可以是BMP里面的访问数据库的代码。从这个意义上来说,HibernateEB不是一个范畴的东西,也不存在非此即彼的关系。 二、Hibernate是一个JDBC密切关联的框架,所以Hibernate的兼容性JDBC驱动,数据库都有一定的关系,但是使用它的Java程序,App Server没有任何关系,也不存在 兼容性问题。 、Hibernate不能用来直接Entity Bean做对比,只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看,Hibernate也是做为JDBC的替代者出现的,而 不是Entity Bean的替代者出现的,让我再列一次我已经列n次的框架结构: 传统的架构: 1) Session Bean <-> Entity Bean <-> DB 为了解决性能障碍的替代架构: 2) Session Bean <-> DAO <-> JDBC <-> DB 使用Hibernate来提高上面架构的开发效率的架构: 3) Session Bean <-> DAO <-> Hibernate <-> DB 就上面3个架构来分析: 1、内存消耗:采用JDBC的架构2无疑是最省内存的,Hibernate的架构3次之,EB的架构1最差。 2、运行效率:如果JDBC的代码写的非常优化,那么JDBC架构运行效率最高,但是实际项目中,这一点几乎做不到,这需要程序员非常精通JDBC,运用Batch语句,调整 PreapredStatement的Batch SizeFetch Size等参数,以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行 效率。EB的架构效率会差的很远。 3、开发效率:在有JBuilder的支持下以及简单的项目,EB架构开发效率最高,JDBC次之,Hibernate最差。但是在的项目,特别是持久层关系映射很复杂的情况下,Hibernate效 率高的惊人,JDBC次之,而EB架构很可能会失败。 4、分布式,安全检查,集群,负载均衡的支持 由于有SB做为Facade,3个架构没有区别。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值