| 我认为Spring的一些负面因素 |
|
javamonkey 原创 更新:2006-10-25 14:59:48 版本: 1.0
|
|
最近一直在忙于学习业务系统和学习c++,对技术框架已经疏于了解。恰好一同事在我项目里使用了spring,并带了些问题,所以决定看看Spring技术,针对我同事带来的这些问题与大家讨论。 主要是些负面的体会。 一。Spring的xml配置很不好。xml滥用程度已经泛滥成灾了。要知道程序员最习惯,最欢迎的还是看代码。当要看一个业务逻辑时发现竟然先要去看它的父类,然后看爷爷类,然后再看太爷爷类,最后发现还需要找Spring配置去找另外一个类,而这个类ref了另外一个类时,肯定哐当晕倒(不知道还有没有父,爷,太爷)。无论是初学语言,还是对技术深入了解的高手,或者还是因为项目紧急从别的地方抽掉过来的其他成员。简单的代码和配置都是合适的(像我这样用了好几年的java的人已经有点不爱看xml配置)。 二。Spring的配置方式不支持开发模式。每次修改Spring配置,总是需要重启动。一些大项目启动是非常耗时的。相反一些别的小的第三方配置开发包可以支持开发模式。另外,我觉得Sping也不太可能支持开发模式,这在下面一点会说到 三。直觉上Spring管的太多。对于很多框架或者第三方lib来说,往往专著于完成系统的某一方面。如Hibernate专著于O/R Mapping,EJB专著于分布,事务,规则引擎专著于解释规则,执行运算等。Spring做的太多使其有啥都做不好的嫌疑,当然这还不是最主要的负面因素,而是他干扰了业务系统。他对对象进行管理有可能会让某些用户用Spring管理业务对象。这有可能带来负面结果的。如一些情况:Struts的MVC被Spring接管,业务逻辑又被Spring接管。一个新手很难看懂代码。了解代码的时候总会遇到“黑洞”。又如上面所说的开发模式,因为业务对象的互相依赖,"重新启动业务对象"是很复杂的一件事情,Spring也不可能做到这一点。除非你的业务对象屈服于Spring的架构,这又和使用Spring初衷违背了。再如,业务对象的复杂性,核心性决定了Spring难以管理好它,也没有必要多此一举. 四。适配器成灾。Spring为了管理好第三方包,只好做些适配器。以方便管理。当然,有些第三方包很简单,不需要做,比如我看到javaresearch.org刚有的一篇文章是在Spring中使用定时器。但是某些复杂的第三方包或者框架就有问题了,得写适配器。如接管某web mvc框架。又如刚才所说的定时器lib,本生功能齐备的定时器lib就有自己的配置,你要去Spring去管理它。只能写个适配器,在适配器中使用定时器lib提供的配置文件 Spring已经被使用了很长时间,肯定是一个被证明过的良好的框架,由于我对其没有实际使用的经验,所以有了些上述体会,欢迎拍砖讨论,让我更了解Spring的优点
|
|
|
评论人:xyz20003
|
发表时间: Thu Oct 26 18:12:05 CST 2006
|
|
没有完美的东西,了解一些负面影响对我也有好处,不过利大于弊。
|
|
|
评论人:xyz20003
|
发表时间: Thu Oct 26 18:19:28 CST 2006
|
|
我觉得啊,spring不是为了让系统更简单的,而是为了更好维护,更良好的可扩展性。
|
|
|
评论人:asthy
|
发表时间: Fri Oct 27 14:42:07 CST 2006
|
|
|
|
评论人:javamonkey
|
发表时间: Fri Oct 27 14:46:07 CST 2006
|
>>我觉得啊,spring不是为了让系统更简单的,而是为了更好维护,更良好的可扩展性。
xyz20003兄,从维护方面来讲,如果整个系统都是基于Spring来配置维护,那么基于Spring本身的技术标准性,维护起来是很方便。但是如果系统还有别的地方配置那么维护起来就麻烦了。我正是最近碰到了这个小矛盾才让我看看Spring的。关于如何能更好的维护,有何建议么?
|
|
|
评论人:mrou2001
|
发表时间: Thu Dec 07 14:33:58 CST 2006
|
加油啊,支持
|
|
|
评论人:lkj107
|
发表时间: Fri Feb 29 16:09:17 CST 2008
|
|
Spring对于java项目来说相当于框架建筑,架构搭好,剩下就是垒砖,主要时间在搭建架构,垒砖可以用小工搞定;框架建筑承重墙少,可以建大型商场(只有几根柱子),后期改变用途布局容易。适于用大型项目,当然还要考虑学习曲线。如果搭个鸡窝,使用框架,那么只能说这个鸡对主人来说相当于牛对于印度人(我的神阿!)。
|
|
|