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好点儿的权限系统了，因此也不得不用它。