Spring的缺点有哪些--Ext扩展

http://www.iteye.com/topic/1131284

1.JavaTear2014 --   发表时间：2013-07-17   最后修改：2013-07-17 

Spring应用比较广泛,本身应该没有什么大问题,只不过就是越来越庞大了,复杂了! 

如果喜欢轻量级别的朋友,我在这里推荐一个(总共也不过500k),它包含Ioc,orm,event,log,job等,已有项目采用这个工具进行开发的,性能还可以! 

Blog:     http://blog.csdn.net/javatear/article/details/8994151

下载地址: http://pan.baidu.com/share/home?uk=2218126399

---------------

sharong --发表时间：2013-07-29   

很多互联网高并发应用启动一次要10分钟以上，但是因为都是nginx配置的集群，在前端感觉不到 

------------------------------------

小te --   发表时间：2013-07-16   

鱼言风语 写道

不支持热部署，是其为数不多的较大的缺点

JRebel就支持Spring的热部署，改个注解什么的都不用重启服务器。 

Eclipse Marketplace里可以在线装，不过这货是收费的，可以试用十多天。 

***************************************

2.iceofst --   发表时间：2013-07-17   

Spring 确实可以使应用程序松耦合，这没有问题。但是DI为我们的带来多大益处我不是特别清楚。 

做了几个项目。项目里面绝大部分类都在用Spring进行管理。很多人写服务的时候都是思维定式：接口+实现类+Spring bean。 

搞到后面，我自己都麻木了。最近一直在思考，Spring到底为我们带来了什么益处，我们是不是正确的、按照框架提供者的初衷在用这个框架，而不是看到别人用我就用。 

我个人理解： 

在不改变架构的前提下，类和类之间的依赖关系是不会消除的。 

我们可以通过各种手段转移类的依赖关系，甚至依赖的方向。 

DI就是一个很好的例子，他做了两件事情：1.把类的依赖关系转移到了框架进行管理，2.反转依赖关系的方向，由框架提供依赖的对象而非自己去取。 

这样做的好处是，使类之间的依赖具有很高的灵活性。我们可以很方便的切换类的实现，而调用方只用单纯的面向接口编程。 

但是问题来了，我们程序里面，确实需要用到上述特性的场景有哪些？ 

比如： 

更易于测试。但是相比专门的测试框架（比如jmock）并没有优势。 

粘合剂。确实方便了多个框架的整合，但是用代码方式来整合也很简单。 

大家是什么想的，求指点。 

---------------------------------

小te--发表时间：2013-07-18  

我觉得Spring可以分为两部分来看： 

1）IoC/DI/AOP 

2) 基于IoC/DI/AOP的集成了其他优秀开源框架的一体化框架 

第一部分前面已经说了中心作用就是“解耦”。 

第二部分可以横向对比一下Ruby里的Rails和PHP里的Zend Framework，都有类似的框架，这些框架之间都有相互借鉴。 

区别就是其它语言的类似框架都是从头到尾自己搞的，而spring是个另类，自己本身的东西很少，都是集成别人的。这得益于java开源世界里资源丰富，没有必要重复发明轮子。Ruby on Rails的插件也很多，不过这个是反的，别人是针对Rails来写插件，Spring则是主动把别的已有框架适配进来，这一点上Spring更高明些。 

另一个区别是其它web服务器端语言一般都是动态的，动态语言的特点是在运行时可以改变自身结构，所以实现插件化非常容易。而Java是静态或者说是半动态的，在Java里要实现类似于动态语言可插拔的特性就要用Spring这样的IoC/AOP框架，因为JDK本身并不提供这样的功能，Spring相当于是对虚拟机进行了hack。 

回过来再说前面的解耦。 

对象之间有一种关系叫依赖关系，就是一个类里调另一个类，另一个类当参数传进去。 

为了降低两个类之间的耦合，我们通常会引入接口，一个类去调另一个类的接口，而不直接调这个类，就是所谓的针对接口编程。 

当然使用接口是有前提的，就是这部分功能会变动会扩展时才有必要引入接口，我总不能为了低耦合搞得系统到处都是接口吧，过度设计是没有必要的。 

问题来了，如果只是一个普通的类没有设计接口怎么来扩展加新功能，而且这个类还是第三方的只有架包没有源码。这时用Spring的DI就简单了，你只需要新写一个类继承原来的类，然后修改一下xml里的bean的配置就把原来的类替换掉了。（当然你只能访问父类里public和protected的数据和方法，private的操作不了） 

AOP也是一样的，用JDK标准的做法你只能拦截实现了指定接口的类，而用了Spring就不一样了，一个普通的类你也可以拦截，用不着接口。AOP典型运用场景比如事物、日志，把规则配上就有了，用不着写程序了。 

再说一下你说的另一个问题，就是在service层写大量的接口。我们知道接口的作用是可以替换成不同的实现，但实际上对于大多数系统service层可能就一种实现，以后也不会替换成其它实现了。那有没有必要写接口，我认为仍然是有必要的。因为service也就是俗称的业务逻辑层表达了这个系统的行为，就是说service确定之后你这个系统能做哪些事情就确定了，所以service的接口是需要认真设计而且也不应该随便修改的。因此service应该被抽取成接口，而且应该加上详尽的注释，service方法的命名可以略长要能清楚的表达这一功能逻辑的意思。 

与之相对应的是DAO层的接口问题。搞java的操作数据库都习惯用DAO，DAO的全称是Data Access Object，业务层调用DAO来访问系统数据。典型的DAO设计模式有一个工厂类、一个接口、一个实现类，网上能找到的示例一般也都是这个样子的。但是，当你使用任何一种设计模式最好是能搞清楚使用场景和它最初的来源。在java里引入DAO最初是为了解决数据库迁移问题，有了DAO就可以用替换实现类的方式在不同数据库之间切换，当时搞java的那帮人甚至yy有了DAO我以后可以不用数据库换成用文件来存数据。所以看清楚了，解决数据库迁移问题，可以在不同数据库之间切换，这正是hibernate干的事情！所以如果你有用hibernate没有手写SQL就没有必要给DAO加接口，如果你有写SQL但肯定不会换数据库也没有必要给DAO加接口，即便是你有写SQL以后也可能会更换数据库那也没有必要现在就给DAO加接口，因为换的时候再加是一样的。 

所以我们对系统进行设计和架构一定是基于场景的。系统设计的一个基本技巧是分析出对业务来说哪些是变量哪些是固定值，一个系统不可能任意灵活，过度设计同样会让系统变得复杂难以维护。基于分析，基于框架，留出必要的扩展就够了。 

---------------------------

低下头是人间 --   发表时间：2013-07-28   最后修改：2013-07-28 

指出几个问题： 

1. 动态语言的特性是运行时可以改变某个类的结构，比如增加一个方法 

Spring并没有使java具备此特性，它也没有对jvm进行任何hack 

2. SpringAOP并没有实现针对类进行代理的功能，它只是使得拦截变得可配置而已。针对类进行代理这一功能是通过cglib实现的。 

3. java引入dao是为了解决java类与数据库表的映射问题，与数据库迁移一点关系都没有。 

********************************************

3. zh_harry -- 发表时间：2013-07-19   

witcheryne 写道

说几个Spring缺点: 

1. Spring 就不应该出来，那时候我就会应为EJB太麻烦，不会走Java这条路。 

2. Spring 为什么没有归到 java 扩展包中，并且成为java默认配置。每次建项目都要配。 

3. Spring ORM太邪恶了，我已经快忘了Hibernate中的方法如何使用。 

4. Spring AOP平时很少用，一般配置好一次不会再动，面试总是有人问，出了知道这是面向切面，其他的没印象。 

5. Spring 为什么要支持JRuby, Groovy之类的脚本。这样我就可以直接使用JRuby或者Groovy作为上层语言，而不是Java中嵌入这类脚本。 

Spring缺点太多了，楼下继续补充.

兄弟你太邪恶了

---------------------------------------

4.Spring Security可以略过. Apache Shiro +1 

去年年底打算重构项目的权限部分，Spring Security & Apache Shiro 同步研究,  最终被Apache Shiro的简单征服了. 

现在用的很舒服. 

-----------------------

小te--发表时间：2013-07-22   最后修改：2013-07-23 

Spring Security比较鸡肋，因为Spring Security是由acegi转过来的，跟spring亲生的Spring MVC可以说是两个级别的东西。 

国内的权限系统通常会比较复杂，而基于Spring Security稍微复杂一点儿的权限系统你就需要自己扩展一堆东西。扩展一堆东西就为了复用一点点功能，跟自己重头实现一个权限系统基本也相差无几了。而且Spring Security的API接口设计得一点儿也不友好，文档也不行，很多时候你不得不去看源码。唯一的好处就是因为是基于Spring的，所以你确实可以基于它扩展出任意复杂的权限系统来。 

我还是五年前用的，当时Spring刚发布3.0版本，Spring Security刚从acegi改名过来。那时候java领域实在是没有比Spring Security好点儿的权限系统了，所以也不得不用它。