技术开发 频道

开发框架:我认为Spring的一些负面因素

  【IT168 技术文档】最近一直在忙于学习业务系统和学习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提供的配置文件

0
相关文章