三大框架mina结构研究报告.docxVIP

三大框架mina结构研究报告 　　问题的提出　　我常常在思考一个问题，我们如何能设计出高水平、高质量的软件出来。怎样是高水平、高质量的软件？它应当是易于维护、易于适应变更、可重用性好的一个系统。如何做到这一点呢？答案当然是“低耦合、高内聚”了。　　低耦合就是软件在构造的时候，各个模块、各个功能、各个类都不会过度依赖于它周围的环境。只有这样，才能使我们的模块在周围发生变更时不受影响，做到易于维护和易于适应变更。正因为如此，也使它更易于重用到其它功能类似的环境中，提高了重用性。　　高内聚则使软件中的各个模块能够各尽其能而又充分合作，也就是对于软件问题空间中需求的各个功能，系统可以合理地把它分配给各个模块来共同完成，而不是一个或几个八面玲珑、包打天下的超级类一个人完成。而对于该系统中的某一个模块，具有自己高度相关的职责，即该职责中的几个任务是高度相关的。每一个模块都决不去完成与自己无关职责的任务。　　那么怎样能构造一个低耦合、高内聚的系统能，时下最流行的框架结构之一的struts+spring+hibernate为我们提供了方便。使用MVC模型，使页面展现与业务逻辑分离，做到了页面展现与业务逻辑的低耦合。当我们的页面展现需要变更时，我们只需要修改我们的页面，而不影响我们的业务逻辑；同样，我们的业务逻辑需要变更的时候，我们只需要修改我们的java程序，与我们的页面无关。使用spring我们运用IoC，降低了业务逻辑中各个类的相互依赖。　　假如类A因为需要功能F而调用类B，在通常的情况下类A需要引用类B，　　因而类A就依赖于类B了，也就是说当类B不存在的时候类A就无法使用了。使用了IoC，类A调用的仅仅是实现了功能F的接口的某个类，这个类可能是类B，也可能是另一个类C，由spring的配置文件来决定。这样，类A就不再依赖于类B了，耦合度降低，重用性提高了。使用hibernate则是使我们的业务逻辑与数据持久化分离，也就是与将数据存储到数据库的操作分离。我们在业务逻辑中只需要将数据放到值对象中，然后交给hibernate，或者从hibernate那里得到值对象。至于用Oracle、MySQL还是SQLServer，如何执行的操作，与我无关。然而我要说的是，即使我们使用了struts+spring+hibernate框架构建我们的软件，就可以做到“低耦合、高内聚”了吗？我认为这是远远不够的！　　我认为我们在使用struts+spring+hibernate框架的时候常常会有以下几个问题值得改进。　　分析与决策　　1.编写DAO的时候不要直接去使用hibernate或spring对hibernate的支持。现在我们在编写DAO的时候普遍都是直接继承spring对hibernate的封装类HibernateDaoSupport，然后使用该类提供的诸如saveOrUpdate(),　　saveOrUpdateCopy(),find()等等。另外，在使用excute()方法实现一些更复杂的hibernate功能的时候还会使用hibernate的类，诸如Query,Session,Type等。这样直接使用spring和hibernate的类存在的问题在于，你的代码将不得不依赖与spring和hibernate的某个版本。比如说，现在hibernate3出来了，改动挺大，实际上最要命的是包结构，hibernate2的包结构是　　*，然而hibernate3是*。同样，spring为了支　　持hibernate3，包名也改为*。假如，你现在新开发一个项目，这没什么关系，如果是升级一个项目问题就来了。如果你希望将你的一个项目从hibernate2升级为hibernate3，你不得不修改DAO中所有对hibernate和spring-hibernate的引用。如果你的代码中出现　　hibernate2与hibernate3不兼容的方法和类，比如saveOrUpdateCopy(),你还将不得不改写。那么你可能会说，我不会这样升级。如果你的软件生命周期有好多年，hibernate升级到4，升级到5，你还是依然使用hibernate2？如果你以这种方式开发一个平台，你能要求所有使用你平台的软件项目都只能使用hibernate2？更进一步说，我现在开发一个产品，今后的客户将是成千上万。经过1、2年我需要升级了，这时我的升级包有几十M，几乎把所有的DAO都换了个遍，这样的升级无异于重装。也许，有人会提出另一个方案，在HibernateDaoSupport与DAO中间增加了一个基础类，这样将基础类中的　　，改为了，这样其下面继承的DAO就不用改动了。然而在源码上是小小的改动，但对于类来说，两个不同版本的HibernateDaoSupp