Spring--也许正成为一个EJB

我在想，如果我开始的时候，换个名字，比如说“Spring被严重滥用”或者是“大家使用Spring时，经常误解了面对接口编程这个概念”，可能会更容易理解一些，可能有些争吵就是不必要的了。应该算是我的失误，虽然本意并非标题党，但还有给人这种感觉。在此说声抱歉了。

最后算是总结一下吧（包括我自己一开始要表达的内容，以及中间想到的一些内容）：

• 我不是什么技术牛人，也从来不敢说自己在哪方面有所擅长，所以我讨论问题的时候，很少用绝对来肯定或者否定某些内容或者观点，因为我的角度永远只是片面的。很多支持Spring的人，因为他们可能用得非常正确，也的确简化了他们的工作，自然是认可的。而反对Spring的人，可能是没有用好，或者用得场合不正确，所以也就反对了。所以支持者和反对者之间并不见得有什么矛盾，更不必言语上有太多的相互冒犯。将自己的立场和场景讲清楚，可能会更好。
• 我从来没有说过Spring没有用，也没有建议大家不用Spring，我只是强调在使用Spring的时候，多多思考，不要教条化。事实上，对于事务，Proxy，还有很多助手类，我也很喜欢用。我对Spring提出的问题在于，它的IOC方式太容易被滥用，当然是否有更好的方案，我也不确认。但这并不妨碍我提出问题。我也说了IOC有很多种方式，Spring的只是一种，大家可以跳出去看一下，学习一些新东西，绝非坏事。
• 主要问题在人，而不一定是技术，Spring也好，EJB也好，都有自己的场合。高手可以用很简单的架构解决很复杂的问题，同样给低手一个再好的架构，也能做烂一个项目。但是Spring在宣传，或者设计上容易让别人误用（也可能是大量不严谨的例子引起的，我经常回头看自己写的一些东西，也会发现当时只是就问题谈问题，给出了一些例子，还是容易误导的）。所以我也一直强调，不能不分场合的滥用，如果这样，那么不管Spring，还是EJB，都存在问题。
• 面向接口编程这个问题，也没有必要细讨论，提出来，供大家参考就OK了。
• 至于我提到的这些问题，都是可以解决的，这个我是同意的，我也提了一些思路，如Spring更合适做模块，模块间可以通过其它的方式来交互，又或者模块间的Spring Context和模块内的Spring Context相互隔离。当然更希望大家能有更好的建议。
• 再加一句，我只希望做技术的人，在使用框架的时候，都有自己的思考，不仅仅是怎么完成工作，更想知道为什么这样做，还有没有更好的方式。我也理解，在中国，深入做技术的确很难，不管是工作压力，强度，还是整个社会，但是有些事情总还是可以考虑的吧。

以下是原来的内容：

引用

本来想注册一个马甲来写这个帖子的，因为估计自己会被骂得很惨。
但是想想还是认了吧。
说个额外的话，大家如果分别看一下支持和反对者说话的语气，就会觉得蛮好玩的。

我不善于写长文章，就简单的说一下自己的看法吧：

• 依赖注入并不是不好，但Spring的依赖注入并不是很好，因为他要强迫很多人员了解别人的东西（你现在要用别人的一个接口，需要配置Spring，那么你必然要找到该接口的实现类，甚至是多个实现类，需要了解别人内部的东西，这叫解耦吗），特别是开发人员水平不高的情况下，基本上就是为了注入而注入，为了接口而接口。
• Spring更合适在模块内部使用，但现在大部分开发人员都做不到模块化设计，而Spring大量的配置文件，将相关内容全局化了，进一步破坏了模块化设计的可能。
• Spring的配置文件太多，而且基本上现在web开发中，都是全局化的，再加上autowire，维护难度远远大于代码。
• 减少了静态编译的机制，增加了不必要的错误。
• 占个位，慢慢补充。

当然有人说，是很多人没有用来Spring，事实上，EJB也是这样，不是EJB不好，而是EJB没有被用好。
就好象API的设计，如果你设计了一个API，却很容易让人误用（或者是进行了错误的宣传），那么责任是使用者还是开发者呢？

大概在7年前，我就不太认同Spring，当然Spring不会因为我的不认同而停止，7年后，情况似乎更严重了。
当时我在CSDN上写的一个Blog: http://blog.csdn.net/wl_95421
我现在仍然想问一个问题：配置文件真的比代码更容易维护吗？

另外说一句，我反对Spring的思路，但是也会用到Spring的一些功能包，比如Jndi的封装等。

估计很多人不同意我的意见，不过希望大家静心讨论一下。

另外说一句，“面向接口编程”，这话里的接口不是java的interface，如果真正翻译一下，应该是“面向抽象编程”，也就是说，将功能抽象出来，然后通过对外的内容提供功能，至于对外的内容是interface，还是class，要看具体的情况。
不是说我写了一个接口，再写一个实现类，就变成“面向接口编程”。
所以也提醒大家注意，回头看一下自己的代码，是否真地对自己的功能进行抽象了，如果说从interface中看出了非常具体的功能，那么这个interface其实就没有什么意义。


我来回答一下问题吧：

引用

Spring完全没有强制你如何写代码

是否强制，这个很难说。仍然是那个建议，java.util.ServiceLoader和Spring两种注入方式，哪种更容易误用呢？一个框架多少都会对使用者施加一定的影响，说没有强制是不大可能的。
问题不在于强制于否，而是在接受的同时，要有自己的思考。
比如说，这种问题Spring有一种解决方式，那么有没有别的方式，思考之后，觉得没有，OK，继续用Spring，如果有，尝试用一下别的内容，也学到了东西，有什么不好呢？但现在这种情况不太普遍吧。

引用

也没看出来你有啥有建设性的建议

我提一个建议，不一定说好，供参考。
将一个大项目分成多个模块项目，模块项目间不使用Spring组装，每个模块都自己清楚的对外功能入口。然后模块内部的Spring文件对外屏蔽，不要外部修改。这样外部使用一个模块的时候，无须去了解Spring文件，而且每个模块内部使用一个相应的ApplicationContext，不会项目所有的模块共享一个Context，可以适当地减少混乱。
当然Spring-DM也有这部分思想的体现，只不过它当时更多是为OSGi来做。
又说到老的话题，Spring也有很多好东西，但好东西往往没有被用好，反而是被用烂了。

引用

如果without spring,你有更好的方案吗？没有，那就接着用吧。

引用

难道兄弟你有更高明的方案？如果没有，请不要乱说！

这句话其实没有意义，每个技术都有适用的场景，有些场景下用Spring也是合适的，但是我看到的情况都是在滥用。为一个功能写一个接口和一个实现类，然后就认为是面向接口编程。这种思路怎么来的，真正用的好吗？我是比较怀疑的。
如果说到方案，只能具体化，打个比方，JDK的ServiceLocator也是非常强大，同时也很简单的。用他同样可以解决很多问题，NetBeans的Lookup也很简单，同样支持了NetBeans。

引用

多么令人蛋疼的观点,发言要靠事实依据,你有证据证明ejb是因为没有被用好才淘汰的吗

EJB一开始就主要目的是为了分布式功能来做的，在当时是没有什么问题的。但在当时有多少项目需要用到EJB呢，很少，但大家提到分布式，就觉得是EJB，本来就是误用。那时候，几乎是言必谈EJB和分布式。
EJB没有被完全淘汰，有很多场合还是用得不错，这些例子我就不用举了吧，只不过90%的情况下是被误用的。

引用

我没投新手，也没投隐藏。但我是为spring叫好的人。你怎么就那么确定为spring叫好的就一定是新手？你怎么就知道人家没有对历史比较？

我不知道为什么说Spring不好，就有人说我水平差，我是混过来的，没有经验装经验，有逻辑关系吗？
就算上面是真的，我一定是年轻人吗？无语的逻辑。

引用

真的不知道你是怎么混过来的。估计也是没什么经验的装有经验吧，我真的很气愤你们这些人，本来没经验就不要装。好像自己其实什么都懂的样子。年轻人不要太浮躁。

我对这话也比较无语了，我虽然不是什么大牛，但代码方面应该也不算太差了。
另外我33岁，不算年轻人了。

引用

个人看JSP真的应该要淘汰了，JSF才是下一个J2EE的领主。让J2EE开发变的更加快捷和高效

至于JSF，我不是特别了解，不好评价。但我也不认为它会是下一个J2EE的领主。

引用

小弟经验不高。但是我想说。天底下没有完美的程序，是程序就有BUG。所以至于任何框架都有 有点，缺点，没有什么淘汰之类的说法。

问题是目前看过来，Spring基本是被滥用，书上给出的例子都往往比较教条，大家照抄，结果不用说了。
当然淘汰这个词用得不是很合适吧，每种技术都有场景，就象cobol多年来还是在用。

引用

占位，我觉得spring挺好的，能解决掉我们开发中的很多问题，减化我们的工作量。我们只用它的core部分就行了，其它你可以不用。如果without spring,你有更好的方案吗？没有，那就接着用吧。

我没有说用还是不用Spring的问题，我只是说Spring现在被严重误用，快成了第二个EJB了。

引用

没办法火了 这种人太恶心了，贬低别人抬高自己，不懂技术非要装懂。如果他真有本事 你就别用Spring

评价一个东西的好坏，和用不用这个东西没有必然联系吧。
我一直在强调误用才是最根本的问题，不是说用不用的问题。

引用

乍一看标题，正想一笑了之，忍不住好奇点开帖子，盼着或有什么惊人之论，也未可知。进来看后大失所望。不是说spring不能被批评，只是楼主通篇除了无病呻吟，实在毫无深度，乏善可陈。不过倒是符合JE评良好无好贴的一贯作风。

无病呻吟不敢苟同，我已经在里面提出了问题，Spring的误用，带来了不必要的复杂度，而且目前很多项目中的设计就是为了接口而接口，我觉得这种情况很严重，而且很多人把IOC等同于Spring的注入，事实上还有很多更好的注入方式，如ServiceLocator（Tuscany基于它实现的，应该不算小项目了吧），NetBeans的Lookup也不用说了。
至于很多人说让我给出一个更好的方案，我的确是没有办法。小项目有小项目的做法，大的有大的，产品型的和普通项目也有区别，怎么可能有一个放之四海而皆准的方案。但现在很多人都认为Spring就是，这才是我想说明的问题。
说实话，我也没有想过去说服别人，只不过正好和一个朋友聊天说到Spring，所以发了这个帖子。
不过结果倒是在我的意料之中。

评论

159 楼 zdmcjm 2011-04-15  

osprey 写道

mercyblitz 写道

superhanliu 写道

ricoyu 写道

引用

但是我看到的情况都是在滥用。为一个功能写一个接口和一个实现类，然后就认为是面向接口编程。这种思路怎么来的，真正用的好吗？我是比较怀疑的。

LZ这段话我超级赞同的, 很多项目都是为了面向接口编程而面向接口编程, 庸人自扰之.
比如很多项目喜欢弄一个service接口, 然后对应一个serviceImpl实现类, 在action里持有这个service接口, 然后通过spring注入唯一的一个实现类serviceImpl, 这就是他们所谓的面向接口编程了.
在这种场景下完全不需要抽象出一个接口, 直接一个service具体类就ok了

同意！！！现在很多项目为了接口而接口，每个具体类都一定要整一个接口，为了接口而接口。实际上很多项目仔细一检查就会发现：接口和实现类的数量是1:1，而不是1：n(n是>1的浮点数)。如果都是1:1，就让人很怀疑这个接口的必要性了：1增加了代码量和复杂度；2增加了配置影响了性能。

这个不能这么说，如果是项目之间有远程调用的话，接口还是必要的，即使是1:1。如果是自娱自乐，那就算了！

上面的各位大仙,难道你们写程序不写单元测试的吗?,你对action的单元测试,如果不写基于service接口的mock,你的单元测试能过吗?测试覆盖率有多少?或者你是连aciton和service一起单元测试的,那dao的mock哪?如果说你是 action,service,dao,数据库表一起测的,那么那就不是单元测试了,是集成测试了!还谈什么弱藕合,或者你们能提供一个不是基于接口的单元测试方案出来,看看需要的hardcode代价是多少.
写代码不只是敲个可以执行的代码出来,还要可维护,可测试,还要有注释,文档.如果没有单元测试,什么重构都是浮云,造出来的是你们自己曾经接收的他人代码(多么看不懂,不可维护),然后自己如法炮制,继续恶心后面的人,如果你们只是认为写代码就是写个可以执行的代码,那不是就自我认知为代码工人,那朝所谓的技术小牛也越来越远了

要对action做单元测试，说明你的代码中，action充刺着大量本不属于action的职责，action本身是简单的，对action做测试，就是蛋疼行为，1＋1＝2需要测试吗？相应的包括什么service测试，dao测试，都需要个mock对象，我不否定mock。但也不是什么都用个mock。如果一个类可以自测试，我还要这些xxx注入干什么。就是因为需要xxx注入，所以项目代码一大坨，测试代也一大坨。

158 楼 JE帐号 2011-04-15  

wl95421 写道

kakaluyi 写道

楼主有个观点有点出入，
Spring的配置文件其实本质是好的，可以将重要组件统一管理，但是我不是赞成对每个类都必须用到IOC去管理，这样很冗余，反而从配置文件中得不到你想要的东西，现在Spring有这个IOC功能，大家都没有想到为什么要这样用，这是想当然的觉得应该这样用，其实Spring的IOC只是设计模式的一种实现方式而已，就像不能为了使用设计模式用设计模式一样，IOC也不是一个应该滥用的地方。这只是三种设计思想的结果:
1依赖倒转
2用工厂模式管理单例
3面向抽象编程
其实核心思想只要是个程序员都可以去实现这些功能,不是很复杂，在没有spring前，我们也不会所有的类都去实现前三种设计模式，所以spring不会成为下一个Ejb,而是spring的一些开发人员的滥用让其他一部分不认同spring的人感到蛋疼！

我不是不认同Spring，我也认为Spring在很多地方不错，只是我对他的IOC实现有些不认同（以现在的眼光），但并不代表我认为他错，我只是觉得有更好的方式来做。
事实上在我看过的代码中，Spring被正确的使用的比例远远低于正确使用的比例。
我最反感的不是Spring的IOC，而是太多人完全不了解为什么用Spring，什么时候用Spring，纯粹是为了Spring而Spring。

先尝试总结你的观点
1.spring不是不好;
2.很多人对spring的使用是不正确的;
3.一个工具或者框架让很多人很容易错误的使用也说明这个工具或框架有问题.

不知这里理解是否正确?
我的一些异议主要集中在第3点上,我想要想让大部分人不用错,可能只有把学习曲线尽量降低,把门槛尽量降低了(需知道,对于不主动学习的人,你的文档再翔实,示例再全面也是无用的),但是另外一方面,把门槛尽量减低通常意味着封装的更深入,细节隐藏的更多,反而导致使用者更难进步.考虑一下VB这门语言,开始时很简单,但是当你度过蜜月期开始需要需要用它做一些复杂东西的时候,就会发现比使用别的语言更麻烦,因为除了解决问题本身,你还给扩充甚至Hack VB这门语言.所以,恐怕有些学习曲线还是应该的,这句话不是仅针对Spring,而是所有的通用性的语言或架构或工具.除非你是做一个DSL,因为不用考虑通用,在单个领域内将抽象与直白结合起来还是存在可能的.


最重要的一件事,我想说的,Spring所谓的轻量级并不是指"易用性"更不包括什么"上手快",事实上"轻量级"的真正语义是"容器无关,架构无关",而所谓的"易用性"其实也是因为"容器无关,架构无关"而带来的好的副作用.
所以,我想说的是,无论如何Spring都成不了EJB,两种完全不同的思路,EJB走的路类似于微软的那套大而全,而Spring走的则是小而精,更开放一些.

所以说即便明天Spring被别的取代了,其实也说明Spring本身的开发有问题,但是和EJB的没落进行关联,确实不是个恰当的类比,需知道,连EJB3都已经和那个被抛弃的EJB2不一个思路了.

157 楼 osprey 2011-04-15  

mercyblitz 写道

superhanliu 写道

ricoyu 写道

引用

但是我看到的情况都是在滥用。为一个功能写一个接口和一个实现类，然后就认为是面向接口编程。这种思路怎么来的，真正用的好吗？我是比较怀疑的。

LZ这段话我超级赞同的, 很多项目都是为了面向接口编程而面向接口编程, 庸人自扰之.
比如很多项目喜欢弄一个service接口, 然后对应一个serviceImpl实现类, 在action里持有这个service接口, 然后通过spring注入唯一的一个实现类serviceImpl, 这就是他们所谓的面向接口编程了.
在这种场景下完全不需要抽象出一个接口, 直接一个service具体类就ok了

同意！！！现在很多项目为了接口而接口，每个具体类都一定要整一个接口，为了接口而接口。实际上很多项目仔细一检查就会发现：接口和实现类的数量是1:1，而不是1：n(n是>1的浮点数)。如果都是1:1，就让人很怀疑这个接口的必要性了：1增加了代码量和复杂度；2增加了配置影响了性能。

这个不能这么说，如果是项目之间有远程调用的话，接口还是必要的，即使是1:1。如果是自娱自乐，那就算了！

上面的各位大仙,难道你们写程序不写单元测试的吗?,你对action的单元测试,如果不写基于service接口的mock,你的单元测试能过吗?测试覆盖率有多少?或者你是连aciton和service一起单元测试的,那dao的mock哪?如果说你是 action,service,dao,数据库表一起测的,那么那就不是单元测试了,是集成测试了!还谈什么弱藕合,或者你们能提供一个不是基于接口的单元测试方案出来,看看需要的hardcode代价是多少.
写代码不只是敲个可以执行的代码出来,还要可维护,可测试,还要有注释,文档.如果没有单元测试,什么重构都是浮云,造出来的是你们自己曾经接收的他人代码(多么看不懂,不可维护),然后自己如法炮制,继续恶心后面的人,如果你们只是认为写代码就是写个可以执行的代码,那不是就自我认知为代码工人,那朝所谓的技术小牛也越来越远了

156 楼 william_ai 2011-04-15  

treblesoftware 写道

这帖子竟然可以被选为良好帖，真是奇迹。
半天没看懂楼主要表达什么，到底是spring的jar的bit快要赶超ejb 2.0的jar了。还是spring提供的功能数量要大于ejb 2.0了。
spring跟ejb面对的应用方面完全就不一样。我觉得拿最新版本的spring跟最新版本的ejb来比较还有可行性。饭后诸葛亮吃不的。

期待新帖 Spring Framework 3.0.5 vs EJB3.1，这样有的放矢一些，省去了很多历史因素。不过，还是感觉挺怪的，将一个框架和一个规范做比较。。。

155 楼 mercyblitz 2011-04-15  

treblesoftware 写道

这帖子竟然可以被选为良好帖，真是奇迹。
半天没看懂楼主要表达什么，到底是spring的jar的bit快要赶超ejb 2.0的jar了。还是spring提供的功能数量要大于ejb 2.0了。
spring跟ejb面对的应用方面完全就不一样。我觉得拿最新版本的spring跟最新版本的ejb来比较还有可行性。饭后诸葛亮吃不的。

看看他人的留言吧，你都没把帖子看懂，你的发言更让人误解！

154 楼 treblesoftware 2011-04-15  

这帖子竟然可以被选为良好帖，真是奇迹。
半天没看懂楼主要表达什么，到底是spring的jar的bit快要赶超ejb 2.0的jar了。还是spring提供的功能数量要大于ejb 2.0了。
spring跟ejb面对的应用方面完全就不一样。我觉得拿最新版本的spring跟最新版本的ejb来比较还有可行性。饭后诸葛亮吃不的。

153 楼 wl95421 2011-04-15  

kakaluyi 写道

楼主有个观点有点出入，
Spring的配置文件其实本质是好的，可以将重要组件统一管理，但是我不是赞成对每个类都必须用到IOC去管理，这样很冗余，反而从配置文件中得不到你想要的东西，现在Spring有这个IOC功能，大家都没有想到为什么要这样用，这是想当然的觉得应该这样用，其实Spring的IOC只是设计模式的一种实现方式而已，就像不能为了使用设计模式用设计模式一样，IOC也不是一个应该滥用的地方。这只是三种设计思想的结果:
1依赖倒转
2用工厂模式管理单例
3面向抽象编程
其实核心思想只要是个程序员都可以去实现这些功能,不是很复杂，在没有spring前，我们也不会所有的类都去实现前三种设计模式，所以spring不会成为下一个Ejb,而是spring的一些开发人员的滥用让其他一部分不认同spring的人感到蛋疼！

我不是不认同Spring，我也认为Spring在很多地方不错，只是我对他的IOC实现有些不认同（以现在的眼光），但并不代表我认为他错，我只是觉得有更好的方式来做。
事实上在我看过的代码中，Spring被正确的使用的比例远远低于正确使用的比例。
我最反感的不是Spring的IOC，而是太多人完全不了解为什么用Spring，什么时候用Spring，纯粹是为了Spring而Spring。

152 楼 kakaluyi 2011-04-15  

楼主有个观点有点出入，
Spring的配置文件其实本质是好的，可以将重要组件统一管理，但是我不是赞成对每个类都必须用到IOC去管理，这样很冗余，反而从配置文件中得不到你想要的东西，现在Spring有这个IOC功能，大家都没有想到为什么要这样用，这是想当然的觉得应该这样用，其实Spring的IOC只是设计模式的一种实现方式而已，就像不能为了使用设计模式用设计模式一样，IOC也不是一个应该滥用的地方。这只是三种设计思想的结果:
1依赖倒转
2用工厂模式管理单例
3面向抽象编程
其实核心思想只要是个程序员都可以去实现这些功能,不是很复杂，在没有spring前，我们也不会所有的类都去实现前三种设计模式，所以spring不会成为下一个Ejb,而是spring的一些开发人员的滥用让其他一部分不认同spring的人感到蛋疼！

151 楼 wxno1 2011-04-15  

1、不光是spring什么都有可能被滥用，不光是框架，就连抗生素也被滥用了呢：）

2、关于XML配置文件过多的情况，使用注解的话会好很多（不过好像多少会失去些自由性）。

3、同意面向接口编程改为面向抽象编程，因为太多人只为接口写一个实现类，没意义。

4、老实说spring对第三方组件良好的扩展真是让我感觉比较好的地方

150 楼 kakaluyi 2011-04-15  

BigBlue 写道

kakaluyi 写道

一个重量级，一个轻量级怎么比较。你想让spring管理的bean放到xml中，想自己代码管理的用自己的工厂方法，多么灵活，我不认同你观点

什么是重量级，什么是轻量级？不要口号，要实际

我EJB和Spring都用过，对于所有组件Spring是可插拔的，比如mail,quartz，或者你不想用声明性事务（某人脑袋短路了？）。
而EJB你想脱离EJB的J2EE侵入式接口，把你的代码复用，no-way，所有的组件都是基于EJB的分布式部署，脱离重量级j2EE中间件（jboss,WAS,Wblogic）,你的代码一无是处，连个JMS组件都用不起来，如果你还区分不清楚什么是重量级什么是轻量级，请看Rod-johnson的Expert-without-EJB.

149 楼 wl95421 2011-04-15  

引用

但是时代在进步,Spring也在进步.
现在再讲Spring配置文件过多就不合时宜了.

这个涉及到大家使用Spring的习惯。
至于AutoWire和Annotation，我个人也不是很支持。
如果真正要用，可能XML比Annotation更好一些。
当然这个问题比较扯了，不在这里讨论了。
也许你团队用Spring好一些，问题少一些，但是据我所知，情况未必乐观。

148 楼 lancelotly 2011-04-15  

spring其实就是一个在特定时间，特定场景解决问题的东西，只是现在被滥用的情况确实非常的多，好多项目就是为了spring而spring。

147 楼 liukai 2011-04-15  

wl95421 写道

引用

本来想注册一个马甲来写这个帖子的，因为估计自己会被骂得很惨。

• 依赖注入并不是不好，但Spring的依赖注入并不是很好，因为他要强迫很多人员了解别人的东西（你现在要用别人的一个接口，需要配置Spring，那么你必然要找到该接口的实现类，甚至是多个实现类，需要了解别人内部的东西，这叫解耦吗），特别是开发人员水平不高的情况下，基本上就是为了注入而注入，为了接口而接口。
• Spring更合适在模块内部使用，但现在大部分开发人员都做不到模块化设计，而Spring大量的配置文件，将相关内容全局化了，进一步破坏了模块化设计的可能。
• Spring的配置文件太多，而且基本上现在web开发中，都是全局化的，再加上autowire，维护难度远远大于代码。
• 减少了静态编译的机制，增加了不必要的错误。
• 占个位，慢慢补充。

引用

依赖注入并不是不好，但Spring的依赖注入并不是很好

虽然我没用过Ejb,但是Spring的DI目前来看应该是事实上的标准了吧?我没听过有其他的框架做的比Spring更好.

楼主也说Spring有大量的配置文件.
我专门数了下我用Spring3MVC做的项目中Spring配置文件.
不算dataSource相关的配置的话
Spring的配置只有5行.
SrpingSource出的STS甚至帮你把写这5行spring配置文件的步骤都省了...

楼主说的Spring大量配置文件也许指的是Spring2.0以前的Spring了
当时Spring的确需要大量的xml配置.
尤其恼火的是每个接口都要手动注入.
项目大了看着N个几百行的xml文件维护起来痛不欲生.

但是时代在进步,Spring也在进步.
现在再讲Spring配置文件过多就不合时宜了.

至于那些说接口编程模式没用的.楼主中间的一段话已经说的很明白了

引用

另外说一句，“面向接口编程”，这话里的接口不是java的interface，如果真正翻译一下，应该是“面向抽象编程”，也就是说，将功能抽象出来，然后通过对外的内容提供功能，至于对外的内容是interface，还是class，要看具体的情况。

请好好的理解这句话的意思
我举个例子,如果你需要处理一个业务逻辑.一个dao里是完成不了的

但我们可以在service上完成.在同一个类里调用多个dao再加上Transactional就可以了

然后在controller调用service接口.

当然你也可以说我直接用存储过程啊.所以service层根本就不需要.

我说一个很简单的东西专门写一个存储过程麻烦不麻烦啊.维护起来麻不麻烦啊.

总的来说Spring是个好东西.
骂他的人很多,喜欢他的人也多,但是都在用他.

146 楼 wl95421 2011-04-15  

fhjxp 写道

不太理解这帖子也只能被评为良好帖子！
如所言：“如果你设计了一个API，却很容易让人误用（或者是进行了错误的宣传），那么责任是使用者还是开发者呢？”，楼主自己误用了（当然也还有相当一部分人误用了），把原因全部推倒Spring上面，然后就认为Spring不好。
其他为了接口而接口、配置文件的问题，希望楼主好好研究一下Spring再来评论，Spring是不存在这些问题的。

我说过Spring存在这些问题吗？我把问题推到Spring上了吗？
我一直在说，大家误用了Spring，而且很严重。
Spring有很多地方，设计的不错。但同样，有些设计也是比较容易误用的，当然这是一个选择问题，我不赞同，并不代表它有问题，毕竟要面对的场景不同，只是个人观点而已。
我更喜欢ServiceLocator,Lookup,Extension Point这些设计。
每种设计都不完美，但如果把一个东西不管场合去用，那么怎么说呢？

145 楼 jlcon 2011-04-15  

Spring使用元注解也可以避免复杂的XML方式的配置，Spring就是一个工具提供了很多功能，如何使用就完全看使用者对工具掌握的熟练程度了

144 楼 madbluesky 2011-04-15  

非常赞同“面向接口编程”应该改为“面向抽象编程”

143 楼 181054867 2011-04-15  

楼主的见解很深刻，就我个人认为，spring在做中小型项目里，其开发时间及学习成本太高。
我一直在寻求一种更快捷但不失灵活的J2EE开发方法，Spring内部提供的功能还是很好的，但使用来做开发难免复杂。
也正如楼主所说，现在用Spring的人基本都是知道大家用而自己用，没有深入理解Spring的思想(当然，要理解不是一件很容易的事情)，也谈不上能把这工具用好啦

当然，我一直没有在工作中使用过Spring，也没有深刻认识到非得要用这东西！

142 楼 wl95421 2011-04-15  

引用

楼主能评价出来spirng的一些误用.滥用.说明你用过,但是你评价出来的这几点.也正好说明你也只是用到了spirng的皮毛.
也就是说.你用的这些个皮毛.其实完全没必要使用spirng都可以实现,或者有更好的办法实现.说以楼主才发了这个帖子.

大家没必要跟帖了.万事万物,一物克一物,天生我才必有用.spring的精华不是楼主你这么两三句就给其否定了.

不知道是我表达有问题，还是别的原因。
我一直在说，如果用Template,Transaction这些东西，我觉得很OK了，简化了开发，没有任何问题。
但现在就是你说的那些皮毛的内容，却大量被使用，而且不管场合地使用。
就象你说的，现在有多少没有必要用Spring实现的东西，都被硬套上了Spring。
现在大家回头看一下团队的代码，哪些内容是用了精华的东西，哪些内容是为了接口而接口，我不好臆断到底有多少，但绝对不少。
Spring也有精华所在，我也没有去否认这些东西。
我只是想提醒大家，Spring现在被滥用的很严重，而且很多地方有误导的情况，希望大家使用的时候，多想一下。

141 楼 lijunlong 2011-04-15  

spring能在一定的范围内解决一定的问题，使用起来优点多于缺点

140 楼 fhjxp 2011-04-15  

不太理解这帖子也只能被评为良好帖子！
如所言：“如果你设计了一个API，却很容易让人误用（或者是进行了错误的宣传），那么责任是使用者还是开发者呢？”，楼主自己误用了（当然也还有相当一部分人误用了），把原因全部推倒Spring上面，然后就认为Spring不好。
其他为了接口而接口、配置文件的问题，希望楼主好好研究一下Spring再来评论，Spring是不存在这些问题的。