Spring Framework 的理解以及可维护性是否得以改善的思考

Spring的特性:
1. 提供了一种管理对象的方法,可以把中间层对象有效地组织起来。一个完美的框架“黏合剂”。
2. 采用了分层结构,可以增量引入到项目中。
3. 有利于面向接口编程习惯的养成。
4. 目的之一是为了写出易于测试的代码。
5. 非侵入性,应用程序对Spring API的依赖可以减至最小限度。
6. 一致的数据访问介面。
6. 一个轻量级的架构解决方案。

对Spring的理解
Spring致力于使用POJOs来构建应用程序。由框架提供应用程序的基础设施,将只含有业务逻辑的POJOs作为组件来管理。从而在应用程序中形成两条相对独立发展的平行线,并且在各自的抽象层面上延长了各自的生命周期。

Spring的工作基础是Ioc。Ioc将创建对象的职责从应用程序代码剥离到了框架中,通常2中注入方式:setter 和 ctor参数。
每个Bean定义被当作一个POJO(通过类名和JavaBean的初始属性或构造方法参数两种方式定义的Bean)。
Spring的核心在org.springframework.beans,更高抽象层面是BeanFactory. BeanFactory是一个非常轻量级的容器。

关于可维护性的思考
Spring之类的技术确实带来了应用系统的可维护性的提高吗?
Ioc, AOP之类的技术,本质上都是将原本位于应用程序代码中"硬编码"逻辑,剥离出来放到了配置文件中(或者其他形式)。主流声音都是认为提高了应用程序的可维护性。

但如果从以下方面观察,结合项目实际经验,个人感觉这些技术的应用大大降低了应用程序的可维护性,尤其是面对一个陌生的系统,或者项目人员变动频繁的时候。
1. 中断了应用程序的逻辑,使代码变得不完整,不直观。此时单从Source无法完全把握应用的所有行为。
2. 将原本应该代码化的逻辑配置化,增加了出错的机会以及额外的负担。
3. 时光倒退,失去了IDE的支持。在目前IDE功能日益强大的时代,以往代码重构等让人头痛的举动越来越容易。而且IDE还提供了诸多强大的辅助功能,使得编程的门槛降低很多。通常来说,维护代码要比维护配置文件,或者配置文件+代码的混合体要容易的多。
4. 调试阶段不直观,后期的bug对应阶段,不容易判断问题所在。
5. 性能问题。虽说硬件性能日新月异,但是性能也是在不经意间一点一点地流失的。从汇编到高级语言,到面向对象,到虚拟机,一直处于这样的发展趋势。

Feedback

# re: Spring Framework 的理解以及可维护性是否得以改善的思考[未登录]  回复  更多评论   

2008-07-07 18:17 by 英雄
对你提到的spring大大降低了应用程序的可维护性,我有几点争议:
我们的应用说到底就类似是一本说明书。spring利用ioc,aop两个概念,其实给出了说明书的表述结构。IOC给出了对象的生命周期描述框架(类似说明书中出现的目录),AOP给出了横切式的描述方式(类似说明书中出现的附注)。剩下的部分,我们就开始在IOC的基础上描述系统启动后要建立哪些对象,对象间如何相互引用,每个对象是随叫随生还是保持唯一,每个对象提供哪些服务,具体实现的细节;我们还要时不时加点附注,主要是事务控制。这些描述之后,再加上spring对web层的薄薄的封装描述(类似阅读须知罢),整个说明书描述结束。
所以从这个角度,我认为spring的这两项技术应用,使应用程序的逻辑标书更加简洁清晰完整。至于一部分描述出现在配置文件中这只是个形式,并没有什么问题。
关于spring的配置文件,即使不能找到一些插件啊之类的工具来管理,也可以自己写一些东西来帮助管理。如果你所在的项目还在手工书写和维护配置文件,而且是巨大的配置文件,那确实是非常头大的。
IOC+AOP不仅仅给出了一个完整的描述结构,同时这两个大模式也强有力地规范了代码,统一了程序员的编程方式,应该说合理地使用spring能带来类间的高度解耦,保证享受到面向对象,面向方面编程实践的好处。

# re: Spring Framework 的理解以及可维护性是否得以改善的思考  回复  更多评论   

2008-07-08 19:40 by ek
写的不错,的确实用。
既然路过这里,推荐一个jee视频学习的网站
http://bbs.langsin.com/index.php?fromuid=172

# re: Spring Framework 的理解以及可维护性是否得以改善的思考  回复  更多评论   

2008-07-17 23:08 by bluoy
@英雄
谢谢你的精彩回复。
确实,我当然也感受到了spring带来的种种好处,就好像从汇编到C,从过程到OO一样,软件进化进程的每一环节都确实给许多开发者带来了好处。

本文主要是想换个角度思考一下。在这里,我和你的观点恰好相反了,我认为就是因为形式上的不一致,给开发者带来了很多困惑。尤其是用配置语法来描述程序逻辑,而目的仅仅是为了满足许多凭空想象的,子无虚有的灵活性,可配置性(好像敏捷开发所抵制的一样),打断了过程中的连续性。

再好比现在多如牛毛的各种中间件,本意都是好的,代码复用,提高开发效率,代码质量。但现实往往与预期相反,开发者首先需要想学习一大堆中间件。学习曲线并未降低,项目进度并未改善,项目质量也乏善可陈。

也许,事物就是在矛盾中发展的吧,所谓有利就有弊嘛。

只有注册用户登录后才能发表评论。


网站导航: