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

评论

179 楼 osprey 2011-04-15  

mercyblitz 写道

osprey 写道

mercyblitz 写道

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代价是多少.
写代码不只是敲个可以执行的代码出来,还要可维护,可测试,还要有注释,文档.如果没有单元测试,什么重构都是浮云,造出来的是你们自己曾经接收的他人代码(多么看不懂,不可维护),然后自己如法炮制,继续恶心后面的人,如果你们只是认为写代码就是写个可以执行的代码,那不是就自我认知为代码工人,那朝所谓的技术小牛也越来越远了

小兄弟呀，接口的实现类是不是你自己写的？对于业务实现，你是要测试接口还是实现类呢？


OK，我来细细说一下，自己定义的接口难道还搞一个Mock去测试，为什么要Mock，你看看Spring Test里面，它是针对JEE标准接口而言，比如ServletRequest这类的接口，因为标准技术提供一个规约，这个具体实现不用关心，JEE容器提供实现。容器方面的话，你不用太过于测试。但是在你的单元测试代码中依赖了这些接口，通过Mock的方法来模拟输入，断言输出。

你说的Action一起测试的问题，是单元测试粒度的问题。

对于业务实现，你都自己知道怎么实现的啦，还要去Mock一个对象吗？

比如：

A 类依赖于 B接口，那么你很清楚B接口只有一个实现B1，那么你在做A的单元测试的时候，有必要去做B的Mock吗？

在其他地方传入B接口实例是就是B1,为什么不直接传入B1实例呢？前提是B1的单元测试必须保证，即使没有保证的话，可以通过A的单元测试回归。

所以，你所说的“那朝所谓的技术小牛也越来越远了”，过于理论化，学习技术建议抱有怀疑的态度，什么能做比较重要，不能做更重要！

最后，送你一句话吧！纸上得来终觉浅，绝知此事要躬行

就是因为现在我们用的是maven+jenkins+sonar 所以有jenkins做持续构建并跑单元测试覆盖率,正因为我们现在的团队人数多,所以开发时不是由一个人从action写到dao,而是横切并行开发的,由专门的人写servcie和公用service.所以自己写的action自己要写mokc单元测试,而不是串行的等待其他人的servcie写完再测,至少是自扫门前雪,action行覆盖率要到85%,service的覆盖率要到90%.这也许与开发模式相关.但相比以前自己写个网页点点,算是从action测到dao层,至少从项目上线后一个月看,不像以前狂改bug了,整个项目的bug都集中在页面的体验上了,而不是诡异的throw null啊,业务逻辑异常.这个就是我的体验,不知道算不算绝知此事已躬行

看看我前面的帖子，如果是远程调用或者API级别，是要做Mock确实没有错。这是单元测试的策略问题，呵呵。如果多部门的协作就复杂了，建议还是不要设计复杂的接口类型，采用简单类型过度，等需要的时候在添加上去，这样你没有办法保证接口实现是不是100%可靠，到时候他那边做了任何修改，如果没有通知到你的话，这样事故责任不好定位。因此，这些是开发流程的问题。但不是每个实现都需要接口，上面的意思是说过度设计接口带来了负责，其实没有必要。一个简单的功能没有必要用多层封装，保持简单就OK了。

一个简单功能是没有必要多层封装，有NCSS检测在sonar哪里等着的:(,反正我们开始写单元测试和mock，并且要求覆盖lv时，情绪也很不好，直到上线后，反而比以前轻松不用定着大压力改bug重复上线，从里面挖点作复用也觉得放心很多。接口的修改有svn和文档追踪的，反正比较好界定。而且有sonar的findbugs和checkstyle管着，觉得自己写的代码比开源的代码也比较接近了，至少知道一些不好的编程实践，改掉自己的编程的一些不好习惯，而不是没有单元测试，没有findbugs，写了代码也不知道好不好，哪里好，哪里不好，脚踩西瓜皮的

178 楼 zdmcjm 2011-04-15  

osprey 写道

zdmcjm 写道

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注入，所以项目代码一大坨，测试代也一大坨。

这个我只能说,在系统中1+1=2是需要测试的。你自己没有实现junit，不代表没有项目没有实现，如果举大点，现在稍微著名的开源框架或工具都有junit的代码的，这才能保证该框架或工具至少不是满地bug的。我建议你可以看看单元测试的内容，不管是传统的瀑布开发模型还是最新的敏捷模型，都要求单元模块测试，这是基础。“action本身是简单的，对action做测试，就是蛋疼行为”这是想当然的行为，“用眼睛看看猪肉质量就可以了，是简单的，所以不用仪器检测，所以瘦肉精猪肉就进来了，双汇就蛋疼了"

算了，关于测试的问题，爱测就测吧，那是不是最好连sun的编译器，你用的tomcat，你用的spring，把他的ApplicationContext之类的方法全部测试过，一个方法也不要漏，就算"spring".equals("spring")也要测，总之，是代码就要测试，不然系统上不了线哟。

177 楼 mercyblitz 2011-04-15  

osprey 写道

mercyblitz 写道

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代价是多少.
写代码不只是敲个可以执行的代码出来,还要可维护,可测试,还要有注释,文档.如果没有单元测试,什么重构都是浮云,造出来的是你们自己曾经接收的他人代码(多么看不懂,不可维护),然后自己如法炮制,继续恶心后面的人,如果你们只是认为写代码就是写个可以执行的代码,那不是就自我认知为代码工人,那朝所谓的技术小牛也越来越远了

小兄弟呀，接口的实现类是不是你自己写的？对于业务实现，你是要测试接口还是实现类呢？


OK，我来细细说一下，自己定义的接口难道还搞一个Mock去测试，为什么要Mock，你看看Spring Test里面，它是针对JEE标准接口而言，比如ServletRequest这类的接口，因为标准技术提供一个规约，这个具体实现不用关心，JEE容器提供实现。容器方面的话，你不用太过于测试。但是在你的单元测试代码中依赖了这些接口，通过Mock的方法来模拟输入，断言输出。

你说的Action一起测试的问题，是单元测试粒度的问题。

对于业务实现，你都自己知道怎么实现的啦，还要去Mock一个对象吗？

比如：

A 类依赖于 B接口，那么你很清楚B接口只有一个实现B1，那么你在做A的单元测试的时候，有必要去做B的Mock吗？

在其他地方传入B接口实例是就是B1,为什么不直接传入B1实例呢？前提是B1的单元测试必须保证，即使没有保证的话，可以通过A的单元测试回归。

所以，你所说的“那朝所谓的技术小牛也越来越远了”，过于理论化，学习技术建议抱有怀疑的态度，什么能做比较重要，不能做更重要！

最后，送你一句话吧！纸上得来终觉浅，绝知此事要躬行

就是因为现在我们用的是maven+jenkins+sonar 所以有jenkins做持续构建并跑单元测试覆盖率,正因为我们现在的团队人数多,所以开发时不是由一个人从action写到dao,而是横切并行开发的,由专门的人写servcie和公用service.所以自己写的action自己要写mokc单元测试,而不是串行的等待其他人的servcie写完再测,至少是自扫门前雪,action行覆盖率要到85%,service的覆盖率要到90%.这也许与开发模式相关.但相比以前自己写个网页点点,算是从action测到dao层,至少从项目上线后一个月看,不像以前狂改bug了,整个项目的bug都集中在页面的体验上了,而不是诡异的throw null啊,业务逻辑异常.这个就是我的体验,不知道算不算绝知此事已躬行

看看我前面的帖子，如果是远程调用或者API级别，是要做Mock确实没有错。这是单元测试的策略问题，呵呵。如果多部门的协作就复杂了，建议还是不要设计复杂的接口类型，采用简单类型过度，等需要的时候在添加上去，这样你没有办法保证接口实现是不是100%可靠，到时候他那边做了任何修改，如果没有通知到你的话，这样事故责任不好定位。因此，这些是开发流程的问题。但不是每个实现都需要接口，上面的意思是说过度设计接口带来了负责，其实没有必要。一个简单的功能没有必要用多层封装，保持简单就OK了。

176 楼 osprey 2011-04-15  

zdmcjm 写道

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注入，所以项目代码一大坨，测试代也一大坨。

这个我只能说,在系统中1+1=2是需要测试的。你自己没有实现junit，不代表没有项目没有实现，如果举大点，现在稍微著名的开源框架或工具都有junit的代码的，这才能保证该框架或工具至少不是满地bug的。我建议你可以看看单元测试的内容，不管是传统的瀑布开发模型还是最新的敏捷模型，都要求单元模块测试，这是基础。“action本身是简单的，对action做测试，就是蛋疼行为”这是想当然的行为，“用眼睛看看猪肉质量就可以了，是简单的，所以不用仪器检测，所以瘦肉精猪肉就进来了，双汇就蛋疼了"

175 楼 wl95421 2011-04-15  

http4j 写道

翻了9页还没看到特别有水准的评论，也不翻了。按照惯例，这应该是JavaEye每半年就会出现的吵架帖。以后肉饼应该感谢你们的话题带来的流量了。
Spring一个比较特别的地方就是让新手写出的代码看起来没那么差。

我其实也没有想改变什么，更没有建议别人不用，只不过希望大家在使用Spring，以及任何一种工具的时候，能够多多考虑一下，而不是说教条化，真理化。

引用我朋友的一句话：
两个基础尚可的学生，一个用Spring，一个不用Spring。
1-2年后，你再看他们的能力。
我宁愿他们代码差一年，而不是一直差下去。

也正如前面的朋友所说：
现在招人，特别是1-2年工作经验的人，经常是满嘴DI，AOP。根本不知道深入的内容。

我更觉得这种趋势才是最可怕，也是最可悲的。

174 楼 http4j 2011-04-15  

翻了9页还没看到特别有水准的评论，也不翻了。按照惯例，这应该是JavaEye每半年就会出现的吵架帖。以后肉饼应该感谢你们的话题带来的流量了。
Spring一个比较特别的地方就是让新手写出的代码看起来没那么差。

173 楼 HarryAlex 2011-04-15  

这个哥很是DT啊，你没事儿吧？先写上一小段儿，让别人评论；然后再次修改，把别人的评论引用，很是DT啊！

不过你的观点我还是有点儿朦胧的理解，maybe你是一个高手呢。

172 楼 osprey 2011-04-15  

mercyblitz 写道

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代价是多少.
写代码不只是敲个可以执行的代码出来,还要可维护,可测试,还要有注释,文档.如果没有单元测试,什么重构都是浮云,造出来的是你们自己曾经接收的他人代码(多么看不懂,不可维护),然后自己如法炮制,继续恶心后面的人,如果你们只是认为写代码就是写个可以执行的代码,那不是就自我认知为代码工人,那朝所谓的技术小牛也越来越远了

小兄弟呀，接口的实现类是不是你自己写的？对于业务实现，你是要测试接口还是实现类呢？


OK，我来细细说一下，自己定义的接口难道还搞一个Mock去测试，为什么要Mock，你看看Spring Test里面，它是针对JEE标准接口而言，比如ServletRequest这类的接口，因为标准技术提供一个规约，这个具体实现不用关心，JEE容器提供实现。容器方面的话，你不用太过于测试。但是在你的单元测试代码中依赖了这些接口，通过Mock的方法来模拟输入，断言输出。

你说的Action一起测试的问题，是单元测试粒度的问题。

对于业务实现，你都自己知道怎么实现的啦，还要去Mock一个对象吗？

比如：

A 类依赖于 B接口，那么你很清楚B接口只有一个实现B1，那么你在做A的单元测试的时候，有必要去做B的Mock吗？

在其他地方传入B接口实例是就是B1,为什么不直接传入B1实例呢？前提是B1的单元测试必须保证，即使没有保证的话，可以通过A的单元测试回归。

所以，你所说的“那朝所谓的技术小牛也越来越远了”，过于理论化，学习技术建议抱有怀疑的态度，什么能做比较重要，不能做更重要！

最后，送你一句话吧！纸上得来终觉浅，绝知此事要躬行

就是因为现在我们用的是maven+jenkins+sonar 所以有jenkins做持续构建并跑单元测试覆盖率,正因为我们现在的团队人数多,所以开发时不是由一个人从action写到dao,而是横切并行开发的,由专门的人写servcie和公用service.所以自己写的action自己要写mokc单元测试,而不是串行的等待其他人的servcie写完再测,至少是自扫门前雪,action行覆盖率要到85%,service的覆盖率要到90%.这也许与开发模式相关.但相比以前自己写个网页点点,算是从action测到dao层,至少从项目上线后一个月看,不像以前狂改bug了,整个项目的bug都集中在页面的体验上了,而不是诡异的throw null啊,业务逻辑异常.这个就是我的体验,不知道算不算绝知此事已躬行

171 楼 http4j 2011-04-15  

gtssgtss 写道

http://www.iteye.com/problems/62911

觉得spring那么NB的话，帮忙回答下这个问题

不是Spring粉，不过这个问题似乎不太友好。
泛型是编译期就会被擦除的，你让一个运行时的容器去解决编译期的问题，似乎路子本身就不对。

170 楼 lu674035 2011-04-15  

任何事物都有两面性，相信有人比我更熟悉吧！好的一面我们使用，缺点我们规避，我们自己写适合我们的那一部分，Spring完全没有强制你如何写代码。Spring不但代码可以解耦合，配置文件也可以解耦合，关键是你如何看待Spring！如果你能集成各个框架的优点才是高手，只盯着缺点的人永远是新手！

169 楼 http4j 2011-04-15  

ricoyu 写道

引用

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

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

面向接口或者抽象编程，很多人还是没理解到位。不是声明一个interface，再实现一个impl就是面向接口，这是误区。
不过从你的描述看，可能你也不知道cglib和纯Java动态代理在使用上有什么区别？

168 楼 pengpeng99bill 2011-04-15  

wl95421 写道

引用

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

再强调一次，我不是将Spring和EJB进行比较，只是说Spring滥用的情况和当年EJB差不多。
不管具体场景，就用Spring，不管是否合适，只知道定义一个接口和一个实现类。
不清楚“面向接口编程”，就四处定义接口。

其实 看你的标题是可以探讨的，但是当我进入看你的观点的时候，尤其是第三点就发现你不是在说spring是否在成为EJB而是直接的否定Spring。所以我就不得不说话了，spring是否要成为下一个EJB这个我估计其实当初spring团队自己也讨论过，所以才分出了今天这么派别的spring版本，你可以去查一查，比如spring ioc spring aop ,spring DAO spring jms. spring esb 甚至有spring android 太多太多估计要几百字也写不完。这就是为了根据不同的业务分不同的模块出来了，以免各个之间相互依赖，相互牵扯，防止我要用一个东西就要用所有的，其实EJB就是要用一个就需要用所有的，这就是EJB的问题。当然这也是商业问题，因为你要用EJB你就点买EJB容器，那么你花了那么多钱去买我总要给你点东西吧，所以你用到的不用到的我都给你，同时告诉你一堆大道理这个多么多么好，其实那时商家的一种手段。spring已经在避免这一点了。同时他发展的很好。真正做到了他的初衷，就是让开发spring更简单更容易，当然也不能说spring就不会灭亡，这个谁也说不好，java当初那么好现在SUN也没落了啊。所以什么都要看发展。就现在看来spring发展的很好

167 楼 sd6733531 2011-04-15  

新手前来顶顶。
当时学ssh的时候就觉得很困难，想不通为什么要写这么多麻烦的配置。也不理解IOC所谓的解耦如何体现。
也许是我看的书很糟糕吧。有朋友能推荐点好书么

166 楼 math0423 2011-04-15  

不按照规范来，无规则的只以简单实现当前功能为目的的开发是很可怕的。

165 楼 math0423 2011-04-15  

楼主你把自己的体会说出来，很值得学习，而且也是有道理的。很多框架大家都在用，但是多数都不会用，多数人都是人云亦云，照着葫芦画瓢，核心的思想能体会出个1，2来的太少。我觉得你没必要去回答那些上来就反驳你的人，很明显，菜鸟居多。

164 楼 mercyblitz 2011-04-15  

peterwei 写道

昨晚没上来，一下跑那么多了。

过来帮忙呀，呵呵，Spring反对派压力很大呀！

163 楼 wl95421 2011-04-15  

引用

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

再强调一次，我不是将Spring和EJB进行比较，只是说Spring滥用的情况和当年EJB差不多。
不管具体场景，就用Spring，不管是否合适，只知道定义一个接口和一个实现类。
不清楚“面向接口编程”，就四处定义接口。

162 楼 peterwei 2011-04-15  

昨晚没上来，一下跑那么多了。

161 楼 mercyblitz 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代价是多少.
写代码不只是敲个可以执行的代码出来,还要可维护,可测试,还要有注释,文档.如果没有单元测试,什么重构都是浮云,造出来的是你们自己曾经接收的他人代码(多么看不懂,不可维护),然后自己如法炮制,继续恶心后面的人,如果你们只是认为写代码就是写个可以执行的代码,那不是就自我认知为代码工人,那朝所谓的技术小牛也越来越远了

小兄弟呀，接口的实现类是不是你自己写的？对于业务实现，你是要测试接口还是实现类呢？


OK，我来细细说一下，自己定义的接口难道还搞一个Mock去测试，为什么要Mock，你看看Spring Test里面，它是针对JEE标准接口而言，比如ServletRequest这类的接口，因为标准技术提供一个规约，这个具体实现不用关心，JEE容器提供实现。容器方面的话，你不用太过于测试。但是在你的单元测试代码中依赖了这些接口，通过Mock的方法来模拟输入，断言输出。

你说的Action一起测试的问题，是单元测试粒度的问题。

对于业务实现，你都自己知道怎么实现的啦，还要去Mock一个对象吗？

比如：

A 类依赖于 B接口，那么你很清楚B接口只有一个实现B1，那么你在做A的单元测试的时候，有必要去做B的Mock吗？

在其他地方传入B接口实例是就是B1,为什么不直接传入B1实例呢？前提是B1的单元测试必须保证，即使没有保证的话，可以通过A的单元测试回归。

所以，你所说的“那朝所谓的技术小牛也越来越远了”，过于理论化，学习技术建议抱有怀疑的态度，什么能做比较重要，不能做更重要！

最后，送你一句话吧！纸上得来终觉浅，绝知此事要躬行

160 楼 pengpeng99bill 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。

滥用的原因是因为 你根本不了解spring spring根本不代表IOC也不代表任何组件，他代表的是EJB的轻量级，就是所谓的withoutEJB，那么EJB是用来做什么的呢，EJB是JCP所探讨的所有的商业的J2EE的标准和实现。也就是说其实spring是EJB的免费版和轻量版。为什么你不了解spring是因为你很少接触到真正的大项目，问你下你去看看淘宝的招聘，为什么很多都要求会EJB，那是因为他们的项目是由很多很多模块组成的，这些模块的集成怎么办，而EJB正式为这些大项目所出生的，他良好的处理了这些模块间的关系他能帮助他们解决大部分的问题，而不是说一个小小的ERP,CMS系统就需要使用EJB的。可能你的系统是由N个ERP，N个CMS，N个N系统组成的时候这时候你当初用于简单开发一个ERP系统的武器就不够了。spring替代了EJB当然也不是全部替代，80%，而且他有是可以拔插的。举个例子，对于你系统的用户模块的话，你是不是要考虑到安全问题，那么就有了springsecurity而且他对各种功能集成的很好比如SSO 等等这就免去了你复杂的代码重构，其实EJB容器里都是有这些功能的，但是他们是独立的，比如用weblogic你就要了解
weblogic里面怎么配置，用tomcat你就要了解tomcat怎么配置，但是spring把他们都抽象出来了做成了一个统一的配置而且发展的更好。如果有一天用户或者你的老板说我们不用weblogic了我们用JBOSS因为他免费，那么你还要重新开发一套安全框架吗。所以说spring是对我们的开发更加便利更加容易维护更加有效率。当然不是所有的项目都要用spring你要考虑到项目的规划，以及后期的发展。如果你简单的只是做一个小的ERP或者CRM如果你有你们队员里更熟悉的框架。何必要用Spring。乱用spring是因为你们团队不了解spring而不是spring不好，你要先搞明白是先有鸡还是先有蛋在去处理问题。做软件的最重要的是自己的逻辑思维，好好锻炼你的逻辑思维，才能更好的想明白一些问题。软件的开发是要求速度和效率的，并不重视你需要什么框架。而用spring是因为你考虑过对于你的项目spring会给你带来更大的益处。