论坛首页 Java企业应用论坛

Spring--也许正成为一个EJB

浏览 73139 次
该帖已经被评为良好帖
作者 正文
   发表时间:2011-04-14   最后修改:2011-04-16
我在想,如果我开始的时候,换个名字,比如说“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,所以发了这个帖子。
不过结果倒是在我的意料之中。
   发表时间:2011-04-14   最后修改:2011-04-14
不错,把神仙斗倒,把大鬼小鬼放出来

还有那个神马Action -> Service -> DAO 架构是哪位专家设计的?我不是说不好,关键是怎么不说一下什么情况用,什么情况能用呢?这种"架构"明显存在和Refactoring一书相冲突的Smelly Code

----------------------------------------update(这个沙发抢得真好),这是我以前的一个回复,正好表达我的观点:

引用
当Rod提出J2EE without EJB的时候,事实上就已经给J2EE without spring做好了铺垫。因为他还是无法逃离J2EE的魔爪。
J2EE是什么?他是一个平台,一套规范,用来解决“复杂”的企业应用问题,它的最终体现就是App Server。对象是什么?企业应用开发人员。

想做一个又大又全又简单易用的东西,自然有人会说,我为什么要为不需要的功能买单?我想更换其中的某一部分怎么办?

让我们总结一下抽象的层次:
核心库抽象了系统调用
框架和中间件平台抽象了基础API使用模式
各种所谓应用开发平台抽象了开发模式和业务场景模式

每一层抽象,都有规范限制,都加大了约束,最后程序员的能力和活动范围越来越小。而且对于应用开发来说:
1 做同样的事情,不管需不需要,永远要背起容器这个包袱;
2 很多事情只能绕着圈子来做。

对于真的关心解耦,Ioc的人,google-guice也许是更好的选择。
0 请登录后投票
   发表时间:2011-04-14  
说白了,大多数人还是冲着声明式事务去的.
不过现在, 轻量级声明式事务管理,已经不止Spring了
0 请登录后投票
   发表时间:2011-04-14  
spring也不可能全是好的,你可以在所有的时间内解决一个问题,也可以在一定的时间内解决所有的问题,但是不可能在所有的时间解决所有的问题。
另外ejb是好,但是不好用,市场已经说明了,要不然sun也不能黄了。
0 请登录后投票
   发表时间:2011-04-14  
EJB和Spring我都没理解其意义,只是觉得这2个东西用起来都很麻烦,尤其是配置,EJB部署麻烦,Spring的xml配置很麻烦,要用的时候总是要拿一本书一边看一边配置。。。。
0 请登录后投票
   发表时间:2011-04-14  
spring是饺子皮,ejb是个包子,怎么成为呢
0 请登录后投票
   发表时间:2011-04-14  
ppgunjack 写道
spring是饺子皮,ejb是个包子,怎么成为呢

这个很有意思,
spring 不光是饺子皮,现在也在做 混沌皮,豆腐皮。。。
1 请登录后投票
   发表时间:2011-04-14  
占位,我觉得spring挺好的,能解决掉我们开发中的很多问题,减化我们的工作量。我们只用它的core部分就行了,其它你可以不用。如果without spring,你有更好的方案吗?没有,那就接着用吧。
0 请登录后投票
   发表时间:2011-04-14  
难道兄弟你有更高明的方案?如果没有,请不要乱说!
0 请登录后投票
   发表时间:2011-04-14  
引用

事实上,EJB也是这样,不是EJB不好,而是EJB没有被用好。

多么令人蛋疼的观点,发言要靠事实依据,你有证据证明ejb是因为没有被用好才淘汰的吗
你了解ejb,换句话说,你真正用ejb做个多少个项目!!!!!!
如果没有,就别瞎扯误导新人了.......................
话说je越来越多这么无病呻咛的帖子,真看不出意义何在.
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics