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，所以发了这个帖子。
不过结果倒是在我的意料之中。

评论

139 楼 yangxinxyx 2011-04-15  

很赞成楼主的部分观点，我很讨厌SPRING的配置方式，虽然他的一些声时式注入相当好用，但是维护起来，反倒成本有点高了。
相比Spring前生的那本《without EJB》中的代码却是相当的经典，不过Spring的不断发展，将某些不该发展的地方过分发展了。
但是一个东西存在必有它存在的理由

138 楼 malacca 2011-04-15  

我也觉得spring的配置文件，太多太麻烦了。不过总体上还是比较好用的

137 楼 xiaoyu211940 2011-04-15  

对头
spring最主要的误用是对于面向接口编程这块？
Rod等本意是面向抽象编程的
无奈的是 java里面正好有interface关键字 内流满面了
无数码农当圣经了
一个模块的服务等等 就是一个人用要接口干什么不是纯粹没事找抽型的吗？
还有一大堆的dao层 这种东西完全可以抽象出来的

spring架构非常优秀这是不用质疑的
基本上能够将所有的开源软件融合进来
而且提供简便开发
对于依赖的解耦(ioc) 如果没有ioc你要想想你 为了实例化一个对象你要建立多少工厂类等等 要new对象对象才能将功能组装完
你还看到那种框架能够
ejb 用起来就蛋疼

136 楼 accphc 2011-04-15  

linvar 写道

ricoyu 写道

引用

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

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

开始的时候我也这样认为,后来在一个项目中果断去掉接口, 直接一个service具体类,
但是再后来才发现自己错了,接口的编程模式不是凭空而来的,是最佳实践...
特别是在项目大一点的时候,

另外我使用spring也是因为要取他的事务管理,
后来尝试struct2, springmvc, 最后选择springmvc.
spring基本上是使用注释, 只有一个主配置文件,主要是配置数据源,事务管理.

基本就是使用springmvc + spring + mybatis组合,

是注解吧。

135 楼 accphc 2011-04-15  

Spring又没有逼着你非得写接口！

134 楼 george 2011-04-15  

BigBlue 写道

axeon 写道

楼主的观点是正确的，但是你注定要被投新手和隐藏。
为spring叫好的，才真的是新手，不单单对java的历史没有比较，很多在开发语言层面上也没有比较。刚入行就做java，直接就做spring。
你若真的让他用别的语言写个东西，立刻六神无主，如若让他不用spring写java的东西，他也同样六神无主。
这姑且也算是斯德哥尔摩综合征之一吧！

楼主被投新手和隐藏的原因是新手的基数还真的很大，而且很爱发言。

ejb我算是国内第一批用的，做了几个大项目，平心而论，不是那么好用，也不是那么难用。
spring也是国内第一批用的，其实本质上和ejb差不多，一个解决了A问题，带来了B问题，一个解决了B问题，带来了C问题。

但是，我就弄不明白了，spring难道是你亲爹，那么维护着？

比较贴切的评价
我们团队就有这个现象，离了Spring就不会写东西，结果把什么东西都跟Spring搅在一起了，用Webservice要Spring才能用，用个JPA要Spring才能用，很无奈！

这个实在要顶，"Spring控"们离开了Spring，连RMI都不知道是用来做什么的？然后通过Spring认识了RMI，就说RMI的所有特性都是Spring赋予的，这好比发生地震你被压在楼板下，消防员把你救出来了，你却对一只蟋蟀三拜九叩。 这个例子都举过多次，每次都被喷个十几楼。这次楼主提出了这个标题，我看喷楼主的人也快十楼了，看来ITEYE的 javaer们除了喷人和脏话，别得都不擅长啊。

另外，说点实际的：Spring的主要作用“解藕”，这个我想说的是：在实际的项目中，有几个接口的实现类是在后期需要变动的？真正的项目中，宁可动硬件去迎合软件实现，也不敢轻易改变软件内的实现。除非你做的项目 一个月要换八个客户，改变十几种功能，否则你的“解藕”根本就是为当初的开发人为设置了过多的绊脚石。

说得更具体一点，DAO我从来是使用一个通用DAO，根本不需要DAO层接口，Service层后期需要扩展的可能性是最大的，随意Service层可以用一下接口，但是也不一定非要用。   至于控制层，那是根本就不需要接口，我不知道控制层用接口来隔离是为了什么？有谁会做好的Struts2项目，后期硬生生的换成JSF或者其他的控制模式？

所以把众多的实现都用接口代替，然后使用Spring的配置文件，或者annotation一个个注入实现类，或者使用autowire 自动注入实现类，都是不必要的开销。

更实际一些：你可以把项目中，后来可能要改变的实现类的调用处，全部换做上自己的annotation注解，后期，如果项目需要替换某些实现类，可以使用Google guice或者自己写的一个DI工具，把自己标注annotation的类替换掉；
如果项目不需要替换实现类，那就让项目顺畅地跑着。

总体的思路是：我想DI时，才去DI谁，大部分时间我都不DI，所以我也不需要为了未来可有可无的DI做那么多准备，配置那么多文件，做那么多接口。

133 楼 mercyblitz 2011-04-15  

superhanliu 写道

ricoyu 写道

引用

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

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

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

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

132 楼 superhanliu 2011-04-15  

ricoyu 写道

引用

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

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

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

131 楼 mercyblitz 2011-04-15  

hsiss 写道

spring是为了弥补java语言的缺陷产生的,如果使用java语言开发的话,用什么全栈式框架都是一样
1.java语言没有全局变量,而容器本身就是全局的,所以必须要有类似全局变量的概念,所以就出现了ioc(进化历程请看without ejb,有详细介绍,从多sington模式到一个sington的factory模式模式到没有sington的ioc)
2.java语言没有闭包,所以要有aop,什么声明式事务等等,其实都没有解决问题,或者说在java领域是无解的

由以上两点自然引申出来下一个
3.java做的架构只能是贫血模型,所以要有dao

本着大而全、小而全和要做就做全套的精神,orm,web,mvc和其他实用工具包自然就被包含进来了

有时想想，如果用javascript做架构的话都不会这么复杂
但是我们还在使用java，所以我们要用spring或者类似的框架

哥笑了，Spring 是用Java写的，弥补Java语言的不足？

1.需要全局变量吗？要知道好的容器都提供了Context，Tomcat、Cache不是吗？自己不能实现？
2.这个闭包有什么关系？Java语言没有提供API？Spring在JDK 1.2的时候就出来了？事务EJB没有？
3.Java只能做贫血模式，JSF，EJB算什么呢？

你说了这些都和设计有关，和有没有Spring没有一点关系。要知道Spring是Java写的，就好比名词解释，不能用自己解释自己一般。

130 楼 1927105 2011-04-15  

还是自定义适合自己的框架吧，spring比较大众话，但架构思想比较好

129 楼 rmn190 2011-04-15  

看到这个标题的第一反应： 自己当时用Spring时为什么就没能这么明确地提出对Spring的批评意见？而只是崇拜地景仰？

128 楼 linvar 2011-04-15  

ricoyu 写道

linvar 写道

ricoyu 写道

引用

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

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

开始的时候我也这样认为,后来在一个项目中果断去掉接口, 直接一个service具体类,
但是再后来才发现自己错了,接口的编程模式不是凭空而来的,是最佳实践...
特别是在项目大一点的时候,

另外我使用spring也是因为要取他的事务管理,
后来尝试struct2, springmvc, 最后选择springmvc.
spring基本上是使用注释, 只有一个主配置文件,主要是配置数据源,事务管理.

基本就是使用springmvc + spring + mybatis组合,

不知道你的大项目是多大, 我做过的一个项目开发+测试+报表人员, 最多的时候达到上百个, 做了三年才上线, 所谓的service层根本就不抽象出接口来, service层是干嘛的?是"你"实现业务逻辑的地方, 而不是给团队里其他人用的, 分层干嘛?吃饱了撑的给自己找不痛快? 模块间需要调用对方的API, 那么需要提供一个interface给对方用, 自己提供一个实现类做具体的事, 这样最大限度地避免了模块间的耦合.

可能我理解错了, 我以为你说service,handler,dao层都不使用接口,
service层不使用接口可能还行, handler, dao层不使用接口那就是自作自受了,
我觉得使用接口的话,从service层(代表需求)往回写条理比较清晰...

127 楼 hsiss 2011-04-15  

spring是为了弥补java语言的缺陷产生的,如果使用java语言开发的话,用什么全栈式框架都是一样
1.java语言没有全局变量,而容器本身就是全局的,所以必须要有类似全局变量的概念,所以就出现了ioc(进化历程请看without ejb,有详细介绍,从多sington模式到一个sington的factory模式模式到没有sington的ioc)
2.java语言没有闭包,所以要有aop,什么声明式事务等等,其实都没有解决问题,或者说在java领域是无解的

由以上两点自然引申出来下一个
3.java做的架构只能是贫血模型,所以要有dao

本着大而全、小而全和要做就做全套的精神,orm,web,mvc和其他实用工具包自然就被包含进来了

有时想想，如果用javascript做架构的话都不会这么复杂
但是我们还在使用java，所以我们要用spring或者类似的框架

126 楼 shrpcn 2011-04-15  

大家可以花点点时间了解一下 EJB 3.x哦?   再回头看看 Spring 的优势

125 楼 jhaij 2011-04-15  

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

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

124 楼 C.T 2011-04-14  

我同意楼主观点，在开发中，其实很多时看的是项目需要才选用什么技术，不是一种技术就是万能的应用的，不过现在的java方向，还是很多都要求会spirng的，至少你的老板是这样想的。

123 楼 wl95421 2011-04-14  

Spring中有不少东西，还是非常不错的，比如它的Proxy,Template,Transaction等。
我也不反对用这些东西。
但现在的问题是，大家这部分其实用得不多，恰恰是不必要的接口设计了一堆。
如果说更好的方案，Tuscany可比我们一般的系统要复杂地多，但人家用了ServiceLocator这个简单的设计就解决了问题。
所以现在把Spring当成一个放之四海而皆准的东西，才是大家要思考的问题。

问题不在于Spring的场合，而是在于我们有没有去考虑这些场合是否该用Spring。

引用

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

重还是轻，其实没有什么一致的标准。
事实上，当场景复杂的时候，想轻是不太可能的。
Commons-Lang非常轻，但它的场景能和复杂的事务系统比吗。
现在Spring的功能也是非常多，也有上百M的Jar了吧。
如果说大家能分清楚自己需要的Spring模块，也罢了，但现在是吗？大部分情况正好相反吧！
现在一个比较复杂的系统，如果用JBoss+Spring，大家觉得启动快吗？

122 楼 BigBlue 2011-04-14  

zdmcjm 写道

为毛oracle付费，java也有不需要javaee的解决方案，如playframework框架，根本不需有所谓的xxx容器，xxx中间件，xxx注入。
ioc个毛线。
用了ioc就叫解耦？ioc所代来的问题就是，没有容器，你这个类根本就不算一个类，只能说是个严重残疾的类，没有容器，就不能自理了。用ioc还有个毛病就是，让你很容易误用接口，要是需要注入的属性类型不声明成接口，你用ioc干什么呢？用了ioc，你不声明为接口，这跟直接new有什么区别？
你用ioc你就去搞接口吧，搞annotation,置xml吧，spring所声称的解耦，是一个笑话。

spring代来了解耦，解什么耦，你不是被spring牵着鼻子走吗？
我倒是觉得，spring最好用的不是什么ioc，什么aop，而是那些模版类，它给你的方便是实实在在的，确实减少了很多重复的代码量。而不是像ioc这种，减少了"new"而增加了一大堆xml,annotation，解耦个毛。
另外，楼主我支持你。

那些模版类确实是Spring的精华

121 楼 cyan747 2011-04-14  

引用

如果说从interface中看出了非常具体的功能，那么这个interface其实就没有什么意义

我觉得这挺有道理

120 楼 mercyblitz 2011-04-14  

BigBlue 写道

linvar 写道

开始的时候我也这样认为,后来在一个项目中果断去掉接口, 直接一个service具体类,
但是再后来才发现自己错了,接口的编程模式不是凭空而来的,是最佳实践...
特别是在项目大一点的时候,

个别情况可能接口是必须的，但是大部分接口都是浪费

linvar 写道

另外我使用spring也是因为要取他的事务管理,
后来尝试struct2, springmvc, 最后选择springmvc.
spring基本上是使用注释, 只有一个主配置文件,主要是配置数据源,事务管理.

基本就是使用springmvc + spring + mybatis组合,

事务管理有很多办法，不一定非要Spring吧。
另外说到事务管理，EJB做的绝对要比Spring好，实际用一下就知道了

如果是API级别的，通过提供接口，告知客户端怎么调用接口，他们不需要关心实现。如果是自娱自乐，定义太多接口是没有意义的。

务实地做法是，先提供实现，然后再抽象接口，不要为了接口而接口。