【Jsp精品源码栏目提醒】:网学会员,鉴于大家对Jsp精品源码十分关注,论文会员在此为大家搜集整理了“strust_spring_hibernate的优缺点(面试经典) - 招聘面试”一文,供大家参考学习!
struts 框架具有组件的模块化,灵活性和重用性的优点,同时简化了基于 MVC 的 web 应用程序的开发。
优点:Struts 跟 Tomcat、Turbine 等诸多 Apache 项目一样,是开源软件,这是它的一大优点。
使开发者能更深入的了解其内部实现机制。
除此之外,Struts 的优点主要集中体现在两个方面:Taglib 和页面导航。
Taglib 是 Struts 的标记库,灵活动用,能大大提高开发效率。
另外,就目前国内的
JSP 开发者而言,除了使用
JSP自带的常用标记外,很少开发自己的标记,或许 Struts 是一个很好的起点。
关于页面导航,我认为那将是今后的一个发展方向,事实上,这样做,使系统的脉络更加清晰。
通过一个配置文件,即可把握整个系统各部分之间的联系,这对于后期的维护有着莫大的好处。
尤其是当另一批开发者接手这个项目时,这种优势体现得更加明显。
另外,struts 是业界标准(很多成功案例),学习资源丰富,HTML 标签非常优秀缺点:Taglib 是 Struts 的一大优势,但对于初学者而言,却需要一个持续学习的过程,甚至还会打乱你网页编写的习惯,但是,当你习惯了它时,你会觉得它真的很棒。
Struts 将 MVC 的 Controller 一分为三,在获得结构更加清晰的同时,也增加了系统的复杂度。
ActionForms 使用不便、无法进行单元测试(StrutsTestCase 只能用于集成) Struts 跟 Tomcat、Turbine 等诸多 Apache 项目一样,是开源软件,这是它的一大优点。
使开发者能更深入的了解其内部实现机制。
Struts 开放
源码框架的创建是为了使开发者在构建基于 Java Servlet 和 JavaServer Pages(
JSP)技术的 Web 应用时更加容易。
Struts 框架为开放者提供了一个统一的标准框架,通过使用 Struts 作为基础,开发者能够更专注于应用程序的商业逻辑。
Struts 框架本身是使用 Java Servlet 和 JavaServer Pages 技术的一种Model-View-Controller(MVC)实现.具体来讲Struts 的优点有: 1. 实现 MVC 模式,结构清晰使开发者只关注业务逻辑的实现. 2. 有丰富的 tag 可以用 Struts 的标记库Taglib,如能灵活动用,则能大大提高开发效率。
另外,就目前国内的
JSP 开发者而言,除了使用
JSP 自带的常用标记外,很少开发自己的标记,或许 Struts 是一个很好的起点。
3. 页面导航.页面导航将是今后的一个发展方向,事实上,这样做,使系统的脉络更加清晰。
通过一个配置文件,即可把握整个系统各部分之间的联系,这对于后期的维护有着莫大的好处。
尤其是当另一批开发者接手这个项目时,这种优势体现得更加明显。
4. 提供 Exception 处理机制 . 5. 数据库链接池管理 6. 支持 I18N 缺点: 一、 转到展示层时,需要配置 forward,每一次转到展示层,相信大多数都是直接转到
jsp,而涉及到转向, 需要配置 forward,如果有十个展示层的
jsp,需要配置十次 struts,而且还不包括有时候目录、文件变更,需要重新修改 forward,注意,每次修改配置之后,要求重新部署整个项目,而 tomcate 这样的服务器,还必须重新启动服务器,如果业务变更复杂频繁的系统,这样的操作简单不可想象。
现在就是这样,几十上百个人同时在线使用我们的系统,大家可以想象一下,我的烦恼有多大。
二、 Struts 的 Action 必需是 thread-safe 方式,它仅仅允许一个实例去处理所有的请求。
所以 action 用到的所有的资源都必需统一同步,这个就引起了线程安全的问题。
三、 测试不方便. Struts 的每个 Action 都同 Web 层耦合在一起,这样它的测试依赖于 Web 容器,单元测试也很难实现。
不过有一个 Junit 的扩展工具 Struts TestCase 可以实现它的单元测试。
四、 类型的转换. Struts 的 FormBean 把所有的数据都作为 String 类型,它可以使用工具 Commons-Beanutils 进行类型转化。
但它的转化都是在 Class 级别,而且转化的类型是不可配置的。
类型转化时的错误信息返回给用户也是非常困难的。
五、 对 Servlet 的依赖性过强. Struts 处理 Action 时必需要依赖 ServletRequest 和ServletResponse,所有它摆脱不了 Servlet 容器。
六、 前端表达式语言方面.Struts 集成了 JSTL,所以它主要使用 JSTL 的表达式语言来获取数据。
可是 JSTL 的表达式语言在 Collection 和索引属性方面处理显得很弱。
七、 对 Action 执行的控制困难. Struts 创建一个 Action,如果想控制它的执行顺序将会非常困难。
甚至你要重新去写 Servlet 来实现你的这个功能需求。
九、 对事件支持不够. 在 struts 中,实际是一个表单 Form 对应一个 Action 类或DispatchAction,换一句话说:在 Struts 中实际是一个表单只能对应一个事件,struts 这种事件方式称为 application event,application event 和 component event 相比是一种粗粒度的事件。
Struts 重要的表单对象 ActionForm 是一种对象,它代表了一种应用,这个对象中至少包含几个字段,这些字段是
Jsp 页面表单中的 input 字段,因为一个表单对应一个事件,所以,当我们需要将事件粒度细化到表单中这些字段时,也就是说,一个字段对应一个事件时,单纯使用 Struts 就不太可能,当然通过结合 JavaScript 也是可以转弯实现的。
2.Hibernate 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 作者 Gavin 和 LiDO JDO 的CTO,对于 JDO 和 Hibernate 有过一些激烈的争论,我曾经耐心的看了一遍,仍然没有发现针对 Hibernate 真正有力的攻击,那些所谓的攻击无非针对 Hibernate 没有一个 GUI 的配置工具,没有商业公司支持,没有标准化等等这些站不住脚的理由。
补充几点我的意见: 一、Hibernate 是 JDBC 的轻量级的对象封装,它是一个独立的对象持久层框架,和 AppServer,和 EJB 没有什么必然的联系。
Hibernate 可以用在任何 JDBC 可以使用的场合,例如Java 应用程序的数据库访问代码,DAO 接口的实现类,甚至可以是 BMP 里面的访问数据库的代码。
从这个意义上来说,Hibernate 和 EB 不是一个范畴的东西,也不存在非此即彼的关系。
二、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 Size 和 Fetch Size 等 参数,以及在必要的情况下采用结果集 cache 等等。
而一般情况下程序员是做不到这一点的。
因此 Hibernate 架构表现出最快的运行效率。
EB 的架构效率会差的很远。
3、开发效率:在有 JBuilder 的支持下以及简单的项目,EB 架构开发效率最高,JDBC 次之,Hibernate 最差。
但是在大的项目,特别是持久层关系映射很复杂的情况下,Hibernate效率高的惊人,JDBC 次之,而 EB 架构很可能会失败。
4、分布式,安全检查,集群,负载均衡的支持 由于有 SB 做为 Facade,3 个架构没有区别。
四、EB 和 Hibernate 学习难度在哪里? EB 的难度在哪里?不在复杂的 XML 配置文件上,而在于 EB 运用稍微不慎,就有严重的性能障碍。
所以难在你需要学习很多 EJB 设计模式来避开性能问题,需要学习 App Server和 EB 的配置来优化 EB 的运行效率。
做 EB 的开发工作,程序员的大部分精力都被放到了 EB的性能问题上了,反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。
Hibernate 难在哪里?不在 Hibernate 本身的复杂,实际上 Hibernate 非常的简单,难在Hibernate 太灵活了。
当你用 EB 来实现持久层的时候,你会发现 EB 实在是太笨拙了,笨拙到你根本没有什么可以选择的余地,所以你根本就不用花费精力去设计方案,去平衡方案的好坏,去费脑筋考虑选择哪个方案,因为只有唯一的方案摆在你面前,你只能这么做,没得选择。
Hibernate 相反,它太灵活了,相同的问题,你至少可以设计出十几种方案来解决,所以特别的犯难,究竟用这个,还是用那个呢?这些方案之间到底有什么区别呢?他们的运行原理有什么不同?运行效率哪个比较好?光是主键生成, 就有七八种方案供你选择,你为难不为难?集合属性可以用 Set, 以 用 List, 可 还可以用 Bag,到底哪个效率高,你为难不为难?查询可以用 iterator,可以用 list,哪个好,有什么区别?你为难不为难?复合主键你可以直接在 hbm 里面配置,也可以自定义 CustomerType,哪种比较好些?你为难不为难?对于一个表,你可以选择单一映射一个对象,也可以映射成父子对象,还可以映射成两个 1:1 的对象,在什么情况下用哪种方案比较好,你为难不为难? 这个列表可以一直开列下去, 直到你不想再看下去为止。
当你面前摆着无数的眼花缭乱的方案的时候, 你会觉得幸福呢?还是悲哀呢?如果你是一个负责的程序员, 那么你一定会仔细研究每种方案的区别,每种方案的效率,每种方案的适用场合,你会觉得你已经陷入进去拔不出来了。
如果是用 EB,你第一秒种就已经做出了决定,根本没得选择,比如说集合属性,你只能用 Collection,如果是 Hibernate,你会在 Bag,List 和 Set 之间来回犹豫不决,甚至搞不清楚的话,程序都没有办法写。
1. Hibernate 优点 1 对象/关系数据库映射ORM 它使用时只需要操纵对象,使开发更对象化,抛弃了数据库中心的思想,完全的面向对象思想 2 透明持久化persistent 带有持久化状态的、具有业务功能的单线程对象,此对象生存期很短。
这些对象可能是普通的 JavaBeans/POJO,这个对象没有实现第三方框架或者接口,唯一特殊的是他们正与(仅仅一个)Session 相关联。
一旦这个 Session 被关闭,这些对象就会脱离持久化状态,这样就可被应用程序的任何层自由使用。
(例如,用作跟表示层打交道的数据传输对象。
) 3 事务 Transactionorg.hibernate.Transaction 应用程序用来指定原子操作单元范围的对象,它是单线程的,生命周期很短。
它通过抽象将应用从底层具体的 JDBC、JTA 以及 CORBA 事务隔离开。
某些情况下,一个 Session 之内可能包含多个 Transaction 对象。
尽管是否使用该对象是可选的,但无论是使用底层的 API还是使用 Transaction 对象,事务边界的开启与关闭是必不可少的。
4 它没有侵入性,即所谓的轻量级框架 5 移植性会很好 6 缓存机制,提供一级缓存和二级缓存 7 简洁的 HQL 编程 2. Hibernate 缺点 1 Hibernate 在批量数据处理时有弱势 2 针对单一对象简单的增删查改,适合于 Hibernate而对于批量的修改,删除,不适合用 Hibernate这也是 OR 框架的弱点;要使用数据库的特定优化机制的时候,不适合用Hibernate 3. Spring 它是一个开源的项目,而且目前非常活跃;它基于 IoC(Inversion of Control,反向控制)和 AOP 的构架多层 j2ee 系统的框架,但它不强迫你必须在每一层 中必须使用 Spring,因为它模块化的很好,允许你根据自己的需要选择使用它的某一个模块;它实现了很优雅的MVC,对不同的数据访问技术提供了统一的 接口,采用 IoC 使得可以很容易的实现 bean 的装配,提供了简洁的 AOP 并据此实现 Transcation Managment,等等 优点: a. Spring 能有效地组织你的中间层对象,不管你是否选择使用了 EJB。
如果你仅仅使用了 Struts 或其他为 J2EE 的 API 特制的 framework,Spring 致力于解决剩下的问题。
b. Spring 能消除在许多工程中常见的对 Singleton 的过多使用。
根据我的经验,这是一个很大的问题,它降低了系统的可测试性和面向对象的程度。
c. 通过一种在不同应用程序和项目间一致的方法来处理配置文件, Spring 能消除各种各样自定义格式的属性文件的需要。
曾经对某个类要寻找的是哪个魔法般的属性项或系统属性感到不解, 为此不得不去读 Javadoc 甚至源编码?有了 Spring,你仅仅需要看看类的 JavaBean属性。
Inversion of Control 的使用(在下面讨论)帮助完成了这种简化。
d.通过把对接口编程而不是对类编程的代价几乎减少到没有,Spring 能够促进养成好的编程习惯。
e. Spring 被设计为让使用它创建的应用尽可能少的依赖于他的 APIs。
Spring 应用中的 在大多数业务对象没有依赖于 Spring。
f. 使用 Spring 构建的应用程序易于单元测试。
g. Spring 能使 EJB 的使用成为一个实现选择而不是应用架构的必然选择。
你能选择用POJOs 或 local EJBs 来实现业务接口,却不会影响调用代码。
h. Spring 帮助你解决许多问题而无需使用 EJB。
Spring 能提供一种 EJB 的替换物,它们适用于许多 web 应用。
例如,Spring 能使用 AOP 提供声明性事务管理而不通过 EJB 容器,如果你仅仅需要与单个数据库打交道,甚至不需要一个 JTA 实现。
i. Spring 为数据存取提供了一个一致的框架不论是使用的是 JDBC 还是 O/R mapping 产品(如 Hibernate) 。
Spring 确实使你能通过最简单可行的解决办法来解决你的问题。
而这是有有很大价值的。
缺点:使用人数不多、
jsp 中要写很多代码、控制器过于灵活,缺少一个公用控制器