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

评论

199 楼 wl95421 2011-04-15  

引用

也没看出来你有啥有建设性的建议,最搞笑的是你主贴没啥观点,返回来还大量应用回帖的内容充实你的主贴

我有没有提出来建议吗？ 我说Tuscany用JDK的ServiceLoader来支持自身的架构，有兴趣的朋友可以去看一下，那种方式不见得比Spring的配置差。
有兴趣的朋友去看一下NetBeans的Lookup，也能学到很多东西。
我已经提出来了，但有几位去看了呢？只是在质疑我？
很多人根本就没有去看过我说的这些东西，没有了解更多的内容，就是在质疑。

另外“面向接口”这个说法被误解了，我也在主贴中给出了说明，虽然不什么建设性的建议，也至少表明了自己的观点吧。然后说Spring被滥用，有误导倾向。

难道我一定要给出一个方案，才算是有建设性的建议吗？

我也没有用别人的内容来充实自己的主贴，只是对别人的提问加以回答，这也算是盗用吗？

引用

楼主不是一个实在人!

至于我是否实在，我不评价。
我只是希望大家更多地独立思考。
能够对Spring质疑，然后思考自己的用法，然后正确地使用Spring，也同样是好事情。
总比没有人质疑要好一些吧。

就算去看看我上面提到的一些东西，也不算是坏事吧。

198 楼 gml520 2011-04-15  

william_ai 写道

gml520 写道

william_ai 写道

我也想那么搜来着，可是baidu连Spring Framework都查不出来，害得我差点把咖啡喷出来。

百度还不至于差到你的程度。

http://index.baidu.com自己试试，O(∩_∩)O哈哈~

百度指数真的很烂！

197 楼 kjj 2011-04-15  

wl95421 写道

引用

其实我还是希望Spring做一个类似于模块化管理的一个总控制器，而不是要插足于我们代码的每一个角落，当我们什么时候完全依赖spring解决所有问题的时候，那也是Javaer的真正的悲剧。

大家可以看一下身边项目的代码，难道不是已经Spring的红旗已经遍插了吗？

引用

难道不是已经Spring的红旗已经遍插了吗

这句话更像是一句埋怨


怀疑你是不是一个技术人员,也许你做鼓动更适合

spring 红旗插遍那是spring的本事,

spring 你认为spring管得太多了,那是spring的策略,人家有这个条件

据我所知 springmvc 目前势头也不错,很多人新版本计划从struts2转向springmvc

据说springside 的控制器也将转向springmvc

也没看出来你有啥有建设性的建议,最搞笑的是你主贴没啥观点,返回来还大量应用回帖的内容充实你的主贴

这可以不可以看错你是空手套白狼

就当闲聊对待也许更合适,

如果je沦落为这种怨声载道的地方,我想人会越来越少的

ps:楼主不像个实在人

196 楼 lokinell2006 2011-04-15  

BigBlue 写道

kakaluyi 写道

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.

Expert-without-EJB我看过一点点，ejb也用过一点点，所谓的Spring的可插拔也知道一点点，如果你说的是ejb2，我没话可说。如果你说的是ejb3，那我不能认同。
1、在EJB里面你也可以不用声明式事务；
2、如果说大部分spring的代码脱离spring容器也能用，那么，同样程度的ejb3.X的代码也有相同的效果；
3、我不知道脱离了web容器的spring还有多大的用途，如果你强调spring脱离了web容器也能用，那么，ejb3.X也支持javaSE下运行；
4、我还真是不明白为什么一沾了EJB，立马就变成千金了，用称称出来的么？那么敢问刻度定在多少呢？
5、年代变了，已经不是Expert-without-EJB的时代了，别拿那时的眼光来套现在的东西。虽然ejb3.x不是那么近人意，但已经瘦了下来，有很多亮点值得研究借鉴，JavaEE6的大部分模块都能拆开单独用的。而Spring已经变得越来越臃肿，倾向在一个框架内解决所有问题，彼有当年J2EE的架势。
6、我承认，spring目前远比ejb流行，就像10年前ejb流行一样，但是流行的不代表就是好的，只代表一种非理智的盲从。

支持兄弟的看法！

195 楼 wl95421 2011-04-15  

引用

其实我还是希望Spring做一个类似于模块化管理的一个总控制器，而不是要插足于我们代码的每一个角落，当我们什么时候完全依赖spring解决所有问题的时候，那也是Javaer的真正的悲剧。

大家可以看一下身边项目的代码，难道不是已经Spring的红旗已经遍插了吗？

194 楼 kakaluyi 2011-04-15  

<div class="quote_title">BigBlue 写道</div>
<div class="quote_div">
<div class="quote_title">kakaluyi 写道</div>
<div class="quote_div">
<div class="quote_title">BigBlue 写道</div>
<div class="quote_div">
<div class="quote_title">kakaluyi 写道</div>
<div class="quote_div">一个重量级，一个轻量级怎么比较。你想让spring管理的bean放到xml中，想自己代码管理的用自己的工厂方法，多么灵活，我不认同你观点</div>
<br>什么是重量级，什么是轻量级？不要口号，要实际</div>
<br>我EJB和Spring都用过，对于所有组件Spring是可插拔的，比如mail,quartz，或者你不想用声明性事务（某人脑袋短路了？）。 <br>而EJB你想脱离EJB的J2EE侵入式接口，把你的代码复用，no-way，所有的组件都是基于EJB的分布式部署，脱离重量级j2EE中间件（jboss,WAS,Wblogic）,你的代码一无是处，连个JMS组件都用不起来，如果你还区分不清楚什么是重量级什么是轻量级，请看Rod-johnson的Expert-without-EJB.</div>
<br><br>Expert-without-EJB我看过一点点，ejb也用过一点点，所谓的Spring的可插拔也知道一点点，如果你说的是ejb2，我没话可说。如果你说的是ejb3，那我不能认同。 <br>1、在EJB里面你也可以不用声明式事务； <br>2、如果说大部分spring的代码脱离spring容器也能用，那么，同样程度的ejb3.X的代码也有相同的效果； <br>3、我不知道脱离了web容器的spring还有多大的用途，如果你强调spring脱离了web容器也能用，那么，ejb3.X也支持javaSE下运行； <br>4、我还真是不明白为什么一沾了EJB，立马就变成千金了，用称称出来的么？那么敢问刻度定在多少呢？ <br>5、年代变了，已经不是Expert-without-EJB的时代了，别拿那时的眼光来套现在的东西。虽然ejb3.x不是那么近人意，但已经瘦了下来，有很多亮点值得研究借鉴，JavaEE6的大部分模块都能拆开单独用的。而Spring已经变得越来越臃肿，倾向在一个框架内解决所有问题，彼有当年J2EE的架势。 <br>6、我承认，spring目前远比ejb流行，就像10年前ejb流行一样，但是流行的不代表就是好的，只代表一种非理智的盲从。</div>
<p>   朋友，如果你说的是ejb3的话，我赞同你的除了3之外的其他观点，spring其实只是一种简化编程的框架，并不局限于web和j2se，与此类推EJB也是如此。我觉得我们思路还是比较接近的。其实spring现在确实也越来越臃肿，我也很怀疑每个模块都用spring去集成简化代码是否有必要，但是你不能否认Spring让你简化javamail,quartz,JMS等等模块上面提供的巨大便利，而你即使不用spring，我相信10个人写出的javamail应用都是差不多的，而且没有多余花哨的技术能够让你去使用，能够简化的，为什么不去做？</p>
<p>   同时我认为spring 最重要的贡献是让dev不用每次调用dao 自己ugly close() open()数据库connection，声明性事务，和对ORM框架的集成等等，而IOC起到的作用可能只是在设计上实现了:Don't call me , I will call you这种设计思想.我很怀疑在强大的JVM垃圾回收机制下，是否所有的无状态bean都需要IOC工厂去管理是一个很必要的功能.其实我还是希望Spring做一个类似于模块化管理的一个总控制器，而不是要插足于我们代码的每一个角落，当我们什么时候完全依赖spring解决所有问题的时候，那也是Javaer的真正的悲剧。</p>

193 楼 mini_hu 2011-04-15  

Spring就像一个桔子，有人吃桔子肉，有人吃桔子皮（陈皮），也可以不吃。
各取所需吧^-^

192 楼 skydream 2011-04-15  

BigBlue 写道

Expert-without-EJB我看过一点点，ejb也用过一点点，所谓的Spring的可插拔也知道一点点，如果你说的是ejb2，我没话可说。如果你说的是ejb3，那我不能认同。
1、在EJB里面你也可以不用声明式事务；
2、如果说大部分spring的代码脱离spring容器也能用，那么，同样程度的ejb3.X的代码也有相同的效果；
3、我不知道脱离了web容器的spring还有多大的用途，如果你强调spring脱离了web容器也能用，那么，ejb3.X也支持javaSE下运行；
4、我还真是不明白为什么一沾了EJB，立马就变成千金了，用称称出来的么？那么敢问刻度定在多少呢？
5、年代变了，已经不是Expert-without-EJB的时代了，别拿那时的眼光来套现在的东西。虽然ejb3.x不是那么近人意，但已经瘦了下来，有很多亮点值得研究借鉴，JavaEE6的大部分模块都能拆开单独用的。而Spring已经变得越来越臃肿，倾向在一个框架内解决所有问题，彼有当年J2EE的架势。
6、我承认，spring目前远比ejb流行，就像10年前ejb流行一样，但是流行的不代表就是好的，只代表一种非理智的盲从。

赞成！
spring已经不是刚出来的spring了， ejb也不是以前的ejb了，所以以前的一些过于陈旧的想法和观念可以考虑更新一下了。

我对spring最大的不满意，就是spring越来越臃肿，好听的叫做一站式解决方案，难听的就是到处都插一脚。

任何庞大而无竞争者的东西，如论是组织还是知识，都会不可避免的偏离初衷，反而成为后来者的阻碍。

191 楼 BigBlue 2011-04-15  

kakaluyi 写道

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.

Expert-without-EJB我看过一点点，ejb也用过一点点，所谓的Spring的可插拔也知道一点点，如果你说的是ejb2，我没话可说。如果你说的是ejb3，那我不能认同。
1、在EJB里面你也可以不用声明式事务；
2、如果说大部分spring的代码脱离spring容器也能用，那么，同样程度的ejb3.X的代码也有相同的效果；
3、我不知道脱离了web容器的spring还有多大的用途，如果你强调spring脱离了web容器也能用，那么，ejb3.X也支持javaSE下运行；
4、我还真是不明白为什么一沾了EJB，立马就变成千金了，用称称出来的么？那么敢问刻度定在多少呢？
5、年代变了，已经不是Expert-without-EJB的时代了，别拿那时的眼光来套现在的东西。虽然ejb3.x不是那么近人意，但已经瘦了下来，有很多亮点值得研究借鉴，JavaEE6的大部分模块都能拆开单独用的。而Spring已经变得越来越臃肿，倾向在一个框架内解决所有问题，彼有当年J2EE的架势。
6、我承认，spring目前远比ejb流行，就像10年前ejb流行一样，但是流行的不代表就是好的，只代表一种非理智的盲从。

190 楼 simbas 2011-04-15  

80%的web应用并不需要java，当然就更不需要spring了

189 楼 xb_myth 2011-04-15  

pengpeng99bill 写道

mercyblitz 写道

axeon 写道

kjj 写道

引用

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

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

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

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

这种一看就是神码北大X鸟培训出来的这些人值得辩驳吗
为spring 较好的都是新手, 那么找你这么说,springsource里的都是SB了对吧,貌似那些SB都领导开发潮流,反而你这种精英却无奈像个怨妇一样,埋怨这也不好,那也不好,说这话,真不知道啥叫脸红对吧

引用

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

你算是国内第一批用的现在还发这种论调,看来你也不咋长进,还好意思出来显摆,有啥炫耀的,你的经验和资历在帖子中一点看不出来,唯一的解释就是你装 B,丢人不闲脸疼

引用

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

难道EJB是你亲爹,还是你亲妈,注意素质,你这素质让人感叹..............

说Spring庞大的人,spring是分模块的,如果你们还认识英文字母的话,spring怎么庞大,是人家spring公司的发展战略,你完全没有必要在一个应用里每个都用,你蛋疼了吗!!!

就算你黑Spring 也没有必要这么没有理性吧

要知道，培训学校培训出来的才喜欢所谓精通ssh的。
如果你真的经常上springsource，你会发现里面唱反调和质疑的也很多，这对spring才真的是好事儿。

ejb和spring会都一样的，从开始到结束，至于扯到人家公司的战略，我想你没领5毛钱，就不要这么起劲了。

LZ 我挺你，Spring，我刚用的时候就觉得没有什么技术突破，但是不等于说没有价值。很多小公司不能承受EJB的费用，因此选择了Spring。等OpenEJB这样开源产品出来之后，Spring已经占据了市场。

还有一点，不知道为什么很多人这么固执，有技术的东西，不一定有市场。反之亦然，看看Windows和IE就知道了！

在跟你们说一遍spring 不代表SSH 明白吗，spring代表的是withoutEJB而EJB才是SUN的商业级别的J2EE
那么你看看现在的IE为什么会流失那么多的市场 就是因为技术不更新，windows也即将死亡带来的真实IPAD
如果微软在不创新就会更SUN一样。SUN的问题是他没有关注用户而只知道关注程序员。现在的微软已经是什么都不关心的了。出来windows基本没什么了。还有培训学校出来的根本就不精通SSH他们只会写Helloworld和一些编造出来的所谓的工作经验。这是没办法的因为社会发展就是这样，但是如果他依然这样下去不动的话只会和那个唐骏一样。
说spring好并不是说spring什么都好，但是对于现在的JAVA来说spring是拿来免费里面的最好的框架了，没有什么框架可以代替withoutEJB

竟然说微软除了WINDOWS就基本没什么了，我代表KINECT强烈鄙视你。。。那东西是一般公司能做的出来的吗，以后绝对会成为电脑操作方式的革命
我就是培训学校出来的，我承认我不精通SSH，培训学校把我们带进了程序之门，至于以后怎么走就是靠我们自己了，你们大学出来的不也一样不学JAVA（有几个大学开设JAVA课程？），我认为大学让我们学到的最重要的东西是一种学习的方式和态度，这和一个优秀的培训学校异曲同工，现在的大学应届毕业生有几个懂JAVA的。。。
SPRING的优缺点我这么个新手也没什么发言权，spring，EJB，withoutspring和withoutEJB的项目我都做过，小小的感慨下SPRING确实物如其名，是程序开发的春天，当然EJB如果用好了 不比SPRING差，而且SPRING能做的EJB都恩呢工作，SPRING不能做的EJB也能做，而且一些超大规模的项目用EJB会比spring更方便，关键看你怎么用！！！

188 楼 william_ai 2011-04-15  

gml520 写道

william_ai 写道

我也想那么搜来着，可是baidu连Spring Framework都查不出来，害得我差点把咖啡喷出来。

百度还不至于差到你的程度。

http://index.baidu.com自己试试，O(∩_∩)O哈哈~

187 楼 gml520 2011-04-15  

william_ai 写道

我也想那么搜来着，可是baidu连Spring Framework都查不出来，害得我差点把咖啡喷出来。

百度还不至于差到你的程度。

186 楼 william_ai 2011-04-15  

我也想那么搜来着，可是baidu连Spring Framework都查不出来，害得我差点把咖啡喷出来。

185 楼 kjj 2011-04-15  

蛋疼的标题,莫须有的争论,无聊的楼主,纠结的跟贴

184 楼 george 2011-04-15  

william_ai 写道

下午茶时间，看看google和baidu的趋势
http://www.google.com/trends?q=spring&ctab=0&geo=all&date=all&sort=0
http://index.baidu.com/main/word.php?type=1&area=0&time=0&word=spring

不能单独搜索Spring，在西方国家，Spring就是咱们的“春天”，搜索“春天”的人多了，可能西方的小学生写篇出游的作文，都要搜索一下Spring，所以单独搜索"Spring"根本就无法体现出  Spring Framework on java的真正搜索量。

我个人猜测，Spring这个搜索量中，本意是搜索"Spring Framework on java"的人估计都不到 1 / 10

这就像：咱们中国有个java框架叫做“牛”，在百度上每天搜索“牛”的人太多了，你能说其中多少人本意是搜索“牛”java框架的。

183 楼 william_ai 2011-04-15  

下午茶时间，看看google和baidu的趋势
http://www.google.com/trends?q=spring&ctab=0&geo=all&date=all&sort=0
http://index.baidu.com/main/word.php?type=1&area=0&time=0&word=spring

182 楼 mercyblitz 2011-04-15  

osprey 写道

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，写了代码也不知道好不好，哪里好，哪里不好，脚踩西瓜皮的

确实，单元测试是必须的，我是说粒度把握，看情况！

181 楼 osprey 2011-04-15  

zdmcjm 写道

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")也要测，总之，是代码就要测试，不然系统上不了线哟。

还真是自己写的代码覆盖率到不了，该模块是不允许上线的，至于用的产品和框架，由它们自己保证，我们又没有必要测，您说的是气话，走极端了

180 楼 george 2011-04-15