SSH三大框架面试问题资源-CSDN文库

5星 · 超过95%的资源需积分: 9 100 浏览量 2013-12-20 15:16:29 上传评论 4 收藏 154KB DOC 举报

资源推荐

资源详情

资源评论

SSH 优缺点

1.struts

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 来实现你的这个功能需求。

 八、对 Action 执行前和后的处理. Struts 处理 Action 的时候是基于 class 的 hierarchies，很难在 action

处理前和后进行操作。

 九、对事件支持不够. 在 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 的轻量级的对象封装，它是一个独立的对象持久层框架，和 App Server，和 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 之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。

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 中要写很多代码、控制器过于灵活，缺少一个公用控制器

剩余44页未读，继续阅读

评论收藏

内容反馈

as分别

2014-05-08

非常好，讲的不仅仅是SSH三大框架

umuer

粉丝: 0
资源: 4

SSH三大框架面试问题

oracle视图详解

三大框架面试问题

三大框架SSH)面试题

SSH 三大框架

SSH三大框架

ssh三大框架面试题

三大框架ssh原理及面试题

SSH三大框架面试题汇总

java高级ssh三大框架面试题总结

三大框架SSH

SSH三大框架复习

ssh框架面试题

Java面试题专题之SSH框架_ssm框架面试题.docx

Java面试题专题之SSH框架_ssm框架面试题.pdf

java面试大全从基础到web到ssh三大框架

java 三大框架面试题(SSH）

SSH三大框架整合

SSH三大框架的整合

SSH框架面试题

Java工程师面试题(三大框架SSH)

SSH框架面试题目及答案

SSH三大框架笔试面试题

最新资源