网站运营优化 » 编程 » Java Spring框架研究

Java Spring框架研究

Java Spring框架研究

  Spring是一个WEB Framework,和其他框架不同的是它更像一个组合其他框架的框架。

  即他可以很快的将其他Open source组件快速集成到框架中,很快的构建应用系统,如,ORM、事物、对象连接池等。

  他的理念就是避免重复开发。

  之所以有这么多的framework出现,是因为寻求一种轻量级的解决方案,否则EJB即可以解决收有得问题。

  Spring 非常容易上手,而且Spring 可以使你的构架更加得清晰和易于维护和测试。

  简单的配置和易于集成的开发思想,可以使你不必像struts一样遵守那么多的规则和条条框框,而且,完全不会限制你的发挥。

  还有,另一点需要说明的是,易于测试是软件开发中很重要的一环,在真正的软件项目开发中,可以具有良好的体现。

  Spring是一个J2EE框架,管理整个J2EE Achitecture,从持久层直到展示层。

  用TAPESTRY+SPRING+HIBERNATE这种组合应该是比较“超前”的组合,其中Spring+Hibernate已经有可参考的实现,不过用于项目可能还有点单薄。

  这三者入门似乎都容易,可要真正用得好也真不容易,且Spring是1.0 M3,Tapestry是3.0 Beta3,如果真在实际项目中应用,可能要冒一定的风险。

  Spring 可以给你带来良好的bean管理模式,你不需要去建立自己的factory等bean管理工具,只要通过xml配置文件来声明bean,以及beans之间的关系,这样你就可以简单的使用对象的实例了。

  一个良好的J2EE application通常会需要一个“软总线”(soft bus)的architecture,软总线负责组件的生死、寻找、装配,应用开发者只需要在组件里实现业务逻辑就可以了。Spring就是这样的一个“软总线”——在这个意义上,EJB是和Spring类似的,不过EJB的这条总线加入了更多的功能和限制。最典型的一个限制就是:如果使用EJB体系结构,所有组件必须是EJB.在我看来这就是一个巨大的缺陷,它迫使你的application绑定在EJB上面。而Spring对组件几乎是一无所求,只要是Java Bean就可以了,于是你的application将具有更大的灵活性和可移植性。

  Spring的学习和使用可以说是简单到家了。和XP一样,Spring也不要求你全盘依赖它:你可以只使用它的一些utils;如果觉得合适,可以用bean factory作为你的配置管理和组件装配车间;如果再深入一点,可以用它的持久层框架;如果web层有需要,也可以用它的web框架。不像EJB,Spring并不是一个“全有或全无”的一揽子买卖,你可以选择最适合你的东西。

  Spring Framework 是由《Expert One-on-One J2EE Design and Development》一书的作者Rod Johnson编写的一个J2EE应用框架。

  Spring对View称的选择

  Spring自己有一个MVC框架,另外现在已经可以把Spring与Tapestry和Tiles结合使用。我觉得Spring对MVC是没什么挑剔的。

  对其中的IoC、AOP等概念很感兴趣。

  IoC——invsersion of control

  通常的方式,组件必须自己管理自己与其他组件之间的关联。按照IoC的方式,组件之间互不依赖,只依赖于容器。这就是控制的反转。

  IoC容器与一般框架的不同之处,是调用关系的倒置,从而也导致了依赖关系的倒置。

  传统框架的做法是程序调用框架的服务接口来完成某些任务,但是程序组件的生死存灭是程序自己(或者透过垃圾回收)控制的。而IoC容器则反其道而行之,全盘控制组件的生命周期,根据组件的配置信息和依赖关系在不同的时间点调用组件的不同方法。容器成为主动方,而组件是被动方,胶合层则是配置信息。

  这样,IoC让程序员专注于实际需要做的事情,而不是纠缠在依赖关系和生命周期的管理上;另一方面,则需要有专人来进行配置,细化了分工。

  组件类之间的依赖关系是实际存在着的,IoC容器解放的是组件对象的依赖关系。此时,程序员不必因为组件之间的依赖关系硬编码初始化和调用的顺序,这些都通过配置信息来解决,从而极大的增大了灵活性(这一点给我非常棒的感觉)。

  关于IoC的使用,我能想到的是在表现层和持久层中间加入服务层,这个服务层全部被封装成为组件,使用container注册、管理、调用,在表现层决不有一行调用持久层的代码,全部放在服务层中,这样表现层可以选择各种不同的框架,我们有很多对Struts很熟悉的人,当时我也是设计了这样的架构,不过没有container的概念,要想实现诸如缓存、灵活控制事务、认证、支持多种表现层、支持多种持久层等就做不到。如果有了container,我想是不是可以把这些功能全部放在container中来进行,开发的服务组件只由商业逻辑,其它一概不管,全部由container完成。

  至于使用那个container,我还在看,有几个选择:

  PicoContainer 超轻量级,可以随便嵌入到哪里,不过需要自己完成很多代码,来实现我需要的功能,不知道时间是否允许。使用Tape 3 IoC,要用constructor注册,这个也遭到一些非议,这些没有真正使用过,只是感觉,觉得可以省去配置文件,省去设置context,自动找到dependency,不用实现和pico相关的任何接口,方便单元测试(直接new就行啦,不用烦人的mock,呵呵),更多的好处可能仍需观察中。简单是不是一定就是最好的呢?如果够用,我想应该是吧。

  Spring Framework 次轻量级,这个框架就复杂些了,有从头到脚的DIY方案,提供了一个IoC的容器,有很好的和持久层继承的功能,特别对hibernate有参考实现了。他的文档也有比较详细地介绍,不过他采用的是Type 1 IOC,使用xml来注册管理组件,想一下tapestry就要那么多配置文件,就够烦了,还要再来,还没有工具,真是比较头大。

  作者:杨舰

相关文章

  1. 1. 开源 说道:
    Spring框架核心的确轻量级的

发表留言


点击更换验证码