锁定老帖子 主题:Spring--也许正成为一个EJB
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间: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会给你带来更大的益处。 |
|
返回顶楼 | |
发表时间: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的单元测试回归。 所以,你所说的“那朝所谓的技术小牛也越来越远了”,过于理论化,学习技术建议抱有怀疑的态度,什么能做比较重要,不能做更重要! 最后,送你一句话吧!纸上得来终觉浅,绝知此事要躬行 |
|
返回顶楼 | |
发表时间:2011-04-15
昨晚没上来,一下跑那么多了。
|
|
返回顶楼 | |
发表时间:2011-04-15
引用 期待新帖 Spring Framework 3.0.5 vs EJB3.1,这样有的放矢一些,省去了很多历史因素。不过,还是感觉挺怪的,将一个框架和一个规范做比较。。。
再强调一次,我不是将Spring和EJB进行比较,只是说Spring滥用的情况和当年EJB差不多。 不管具体场景,就用Spring,不管是否合适,只知道定义一个接口和一个实现类。 不清楚“面向接口编程”,就四处定义接口。 |
|
返回顶楼 | |
发表时间:2011-04-15
peterwei 写道 昨晚没上来,一下跑那么多了。
过来帮忙呀,呵呵,Spring反对派压力很大呀! |
|
返回顶楼 | |
发表时间:2011-04-15
最后修改:2011-04-15
楼主你把自己的体会说出来,很值得学习,而且也是有道理的。很多框架大家都在用,但是多数都不会用,多数人都是人云亦云,照着葫芦画瓢,核心的思想能体会出个1,2来的太少。我觉得你没必要去回答那些上来就反驳你的人,很明显,菜鸟居多。
|
|
返回顶楼 | |
发表时间:2011-04-15
不按照规范来,无规则的只以简单实现当前功能为目的的开发是很可怕的。
|
|
返回顶楼 | |
发表时间:2011-04-15
新手前来顶顶。
当时学ssh的时候就觉得很困难,想不通为什么要写这么多麻烦的配置。也不理解IOC所谓的解耦如何体现。 也许是我看的书很糟糕吧。有朋友能推荐点好书么 |
|
返回顶楼 | |
发表时间: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发展的很好 |
|
返回顶楼 | |
发表时间:2011-04-15
ricoyu 写道 引用 但是我看到的情况都是在滥用。为一个功能写一个接口和一个实现类,然后就认为是面向接口编程。这种思路怎么来的,真正用的好吗?我是比较怀疑的。
LZ这段话我超级赞同的, 很多项目都是为了面向接口编程而面向接口编程, 庸人自扰之. 比如很多项目喜欢弄一个service接口, 然后对应一个serviceImpl实现类, 在action里持有这个service接口, 然后通过spring注入唯一的一个实现类serviceImpl, 这就是他们所谓的面向接口编程了. 在这种场景下完全不需要抽象出一个接口, 直接一个service具体类就ok了 面向接口或者抽象编程,很多人还是没理解到位。不是声明一个interface,再实现一个impl就是面向接口,这是误区。 不过从你的描述看,可能你也不知道cglib和纯Java动态代理在使用上有什么区别? |
|
返回顶楼 | |