开源技术Struts、Spring、Hibernate(3)

北方民族大学硕士学位论文 开源技术Struts，Spring，Hibernate在MIS开发中的应用研究

品；框架中的服务可以被最终应用直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。而这些紧密相关联的类或者是对现实世界某个实体的抽象，或者设计模式所抽象出的类群（如图2.1 所示）。

软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中（参见图2.2）。或许，人们常把架构和框架混为一谈的原因就在于此。

对象1对象2接口对象3对象n

图2.1类及类群与关系组合成框架

图2.2 框架和架构的关系

从它们三者的关系可以看出，设计模式是对于重复出现的问题的一种可以重用的解决方法，而一个模式提供了一系列特定的类交互。框架由一组紧密关联的classes(类)组成。而架构决策往往会体现在框架之中。清理概念上的误区后，我们接下来具体分析整合框架所需的三种开源技术，即Struts, Spring和Hibernate。

2.2传统的J2EE解决方案及其缺陷

传统的解决方案给了我们这样的映像：J2EE是一个非常好的企业应用设计规范，它采用了大量优秀

-10-

北方民族大学硕士学位论文 开源技术Struts，Spring，Hibernate在MIS开发中的应用研究

的设计思想。J2EE设计的目标，就是让企业应用开发人员能够在一个规范的平台之上，不用考虑具体的技术问题，专注于业务逻辑实现，就可以开发出性能高、稳定性好、可管理的较高水平的系统[4]。在传统的J2EE架构体系中，其业务层主要是靠组件EJB（Enterprise JavaBean）来实现的，而且EJB一直被认为是JavaEE的核心组件，但它的诞生和为之服务的应用领域是大量数据,大量并发访问,要求极高的稳定性,安全性，以及应用分布式数据库，这样它就进入了重量级的范畴，EJB是为了解决复杂问题而设计的，它是为了复杂而复杂。不幸的很多企业级项目根本没有这样的要求，所以不利于大量实际Web应用。典型的企业级J2EE架构主要由JSP＋Servlet＋EJB组成，在大型分布式系统往往采用这种方式，但是在中小型企业Web应用中，采用EJB为中心的J2EE框架，主要有以下几个问题[5]：

（1） J2EE应用程序容易包含过量的“衔接”代码。.

从对许多代码的审校来看，我们总是发现很多代码毫无用处：JNDI查询代码、传输对象、获取和释放JDBC资源的try/catch代码块……。编写和维护这样的衔接代码无疑会占用大量的项目资源（包括人力资源）。而这些资源应该集中应用程序的业务领域。

（2） 许多J2EE应用程序不恰当的使用了分布式对象模型。

这是导致过度代码和代码重复的主要原因之一。在许多情况下，这也是概念性错误；内部分布式程序比供出一地的应用程序更加复杂，而且通常性能也很差。当然，如果业务需求需要使用分布式结构，那么需要实现一个分布式结构，并且接受由此导致的折衷。但是，没有充分理由，不应该这样做。

（3） EJB组件模型过于复杂。

构思EJB是作为J2EE应用程序中实现业务逻辑时减低复杂性的一种方法；不过这一目标从来没有取得成功。

（4）过度使用EJB

EJB本来是为了内部分布式的事务性程序设计的。但是多有的重要应用程序都是事务性的，而发布性不应该成为基本组件模型的组成部分。

（5）事实上，很多“J2EE设计模式”并非设计模式，而是受技术限制的解决方案

分布式的过度使用，以及诸如EJB之类的复杂API的使用，已经产生了许多不可靠的设计模式。因此我们要批判性的进行分析，并且寻找更加简单有效的方法。

（6）J2EE应用程序难以进行单元测试

J2EE API，尤其是EJB组件模型，在敏捷运动开始之前就已经定义好了，因此，它们的设计并没有考虑单元测试的简易性。通过API和隐式规范，在应用程序服务器之外对基于EJB和许多其它J2EE API的应用程序进行测试，其困难程度超乎想象。然而，在应用程序服务器外部进行单元测试是非常重要的，它可以获得测试的高覆盖率，也可以重现许多故障情形，例如数据库连接的丢失。同样，在开发和维护中，这也能够保证测试的快速进行，使得等待重新部署的时间最小化。

（7）某些J2EE技术简直就是失败

这里，最典型的例子就是实体Bean，它已经证明生产力损失惨重，而且面向对象的使用受到极大的约束。

对待这些问题的传统方法就是等待工具的支持来弥补J2EE规范，这就意味着开发者无需纠缠于上述的复杂性。不过这已经非常失败了。基于代码生成方法的工具并没有带来预期的好处，反而显示出其自身的一些问题。在这种方法中，可能要生成所有那些冗长的JNDI查询，传输对象和try/catch快。

一般说来，经验表明框架（framework）比启用基于工具（tool-enabled）的代码生成要好。一个好

-11-

北方民族大学硕士学位论文 开源技术Struts，Spring，Hibernate在MIS开发中的应用研究

多框架通常在运行时通常比生成的代码要灵活得多；在框架中，可能有配置一个小代码块的行为，而不是去改变许多生成的类。在很多情况下，要多次采用代码生成技术生成目标代码，这使得生产率大大减低。构思精巧的框架还能够提供始终一致的抽象，而代码生成无法成功地在整个项目生命期中隐藏签证的复杂性。

基于框架的方法认识到这样一个事实，就是在J2EE拼图中丢失了一块，这一块就是：应用程序开发人员的观点。许多J2EE所提供的东西，例如JNDI，对应程序员的日常活动来说简直太底层了。J2EE规范和API非常不错，但并没有给开发人员提供编程模型；否则，J2EE规范和API会更成功！好的框架补上这一块，并且给应用程序开发人员一个简单的抽象，而且没有牺牲这个平台的核心能力。

认识到框架对于成功的J2EE项目的重要性，许多开发人员和公司尝试编写它们自己的框架，获得了不同程度的成功。在少数情况下，框架达到了它们预期的目的，大幅度降低了费用，提高了生产率。但是，大多数情形中，框架本身的开发和维护开销成了问题，而且框架的设计缺陷也显示出来。由于其核心问题是相通的，使用单个的，广泛使用的框架比一个人闭门造车要好得多。无论一个组织有多么大，它所获得的经验都无法与该产品在很多公司中被广泛使用所获得的经验相提并论。如果框架是公开源码的，其额外的优势就是可能有人贡献新的，它们采用的特性和增强功能。因此，在某些特殊领域，诸如Struts，spring和Hibernate之类的通用框架日益取代了内部框架。

2.3 J2EE的开源技术

目前, J2EE应用确实很流行,从银行，证券系统,到企业信息化平台,甚至一些小公司,都争相使用J2EE应用。几年前, J2EE应用是很“贵族”的产品,那时候使用EJB作为J2EE的核心,开发成本高,部署成本也高,开发者的学习曲线也陡峭。今天,轻量级J2EE应用的流行,让J2EE应用开始进入寻常百姓家。轻量级J2EE应用是对经典J2EE应用的简化,在保留经典J2EE应用的架构.良好的可扩展性.可维护性的基础上,简化了J2EE应用的开发,降低了J2EE应用的部署成本.轻量级J2EE应用让J2EE平台以更快的速度占领电 …… 此处隐藏：3796字，全部文档内容请下载后查看。喜欢就下载吧 ……