论坛首页 Java企业应用论坛

Spring--也许正成为一个EJB

浏览 73153 次
该帖已经被评为良好帖
作者 正文
   发表时间:2011-04-15  
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.
0 请登录后投票
   发表时间:2011-04-15  
1、不光是spring什么都有可能被滥用,不光是框架,就连抗生素也被滥用了呢:)

2、关于XML配置文件过多的情况,使用注解的话会好很多(不过好像多少会失去些自由性)。

3、同意面向接口编程改为面向抽象编程,因为太多人只为接口写一个实现类,没意义。

4、老实说spring对第三方组件良好的扩展真是让我感觉比较好的地方
1 请登录后投票
   发表时间:2011-04-15  
楼主有个观点有点出入,
Spring的配置文件其实本质是好的,可以将重要组件统一管理,但是我不是赞成对每个类都必须用到IOC去管理,这样很冗余,反而从配置文件中得不到你想要的东西,现在Spring有这个IOC功能,大家都没有想到为什么要这样用,这是想当然的觉得应该这样用,其实Spring的IOC只是设计模式的一种实现方式而已,就像不能为了使用设计模式用设计模式一样,IOC也不是一个应该滥用的地方。这只是三种设计思想的结果:
1依赖倒转
2用工厂模式管理单例
3面向抽象编程
其实核心思想只要是个程序员都可以去实现这些功能,不是很复杂,在没有spring前,我们也不会所有的类都去实现前三种设计模式,所以spring不会成为下一个Ejb,而是spring的一些开发人员的滥用让其他一部分不认同spring的人感到蛋疼!
0 请登录后投票
   发表时间:2011-04-15   最后修改:2011-04-15
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。
0 请登录后投票
   发表时间:2011-04-15  
这帖子竟然可以被选为良好帖,真是奇迹。
半天没看懂楼主要表达什么,到底是spring的jar的bit快要赶超ejb 2.0的jar了。还是spring提供的功能数量要大于ejb 2.0了。
spring跟ejb面对的应用方面完全就不一样。我觉得拿最新版本的spring跟最新版本的ejb来比较还有可行性。饭后诸葛亮吃不的。
0 请登录后投票
   发表时间:2011-04-15   最后修改:2011-04-15
treblesoftware 写道
这帖子竟然可以被选为良好帖,真是奇迹。
半天没看懂楼主要表达什么,到底是spring的jar的bit快要赶超ejb 2.0的jar了。还是spring提供的功能数量要大于ejb 2.0了。
spring跟ejb面对的应用方面完全就不一样。我觉得拿最新版本的spring跟最新版本的ejb来比较还有可行性。饭后诸葛亮吃不的。



看看他人的留言吧,你都没把帖子看懂,你的发言更让人误解!
0 请登录后投票
   发表时间:2011-04-15   最后修改:2011-04-15
treblesoftware 写道
这帖子竟然可以被选为良好帖,真是奇迹。
半天没看懂楼主要表达什么,到底是spring的jar的bit快要赶超ejb 2.0的jar了。还是spring提供的功能数量要大于ejb 2.0了。
spring跟ejb面对的应用方面完全就不一样。我觉得拿最新版本的spring跟最新版本的ejb来比较还有可行性。饭后诸葛亮吃不的。

期待新帖 Spring Framework 3.0.5 vs EJB3.1,这样有的放矢一些,省去了很多历史因素。不过,还是感觉挺怪的,将一个框架和一个规范做比较。。。
0 请登录后投票
   发表时间:2011-04-15  
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代价是多少.
写代码不只是敲个可以执行的代码出来,还要可维护,可测试,还要有注释,文档.如果没有单元测试,什么重构都是浮云,造出来的是你们自己曾经接收的他人代码(多么看不懂,不可维护),然后自己如法炮制,继续恶心后面的人,如果你们只是认为写代码就是写个可以执行的代码,那不是就自我认知为代码工人,那朝所谓的技术小牛也越来越远了
0 请登录后投票
   发表时间:2011-04-15   最后修改: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。


先尝试总结你的观点
1.spring不是不好;
2.很多人对spring的使用是不正确的;
3.一个工具或者框架让很多人很容易错误的使用也说明这个工具或框架有问题.

不知这里理解是否正确?
我的一些异议主要集中在第3点上,我想要想让大部分人不用错,可能只有把学习曲线尽量降低,把门槛尽量降低了(需知道,对于不主动学习的人,你的文档再翔实,示例再全面也是无用的),但是另外一方面,把门槛尽量减低通常意味着封装的更深入,细节隐藏的更多,反而导致使用者更难进步.考虑一下VB这门语言,开始时很简单,但是当你度过蜜月期开始需要需要用它做一些复杂东西的时候,就会发现比使用别的语言更麻烦,因为除了解决问题本身,你还给扩充甚至Hack VB这门语言.所以,恐怕有些学习曲线还是应该的,这句话不是仅针对Spring,而是所有的通用性的语言或架构或工具.除非你是做一个DSL,因为不用考虑通用,在单个领域内将抽象与直白结合起来还是存在可能的.


最重要的一件事,我想说的,Spring所谓的轻量级并不是指"易用性"更不包括什么"上手快",事实上"轻量级"的真正语义是"容器无关,架构无关",而所谓的"易用性"其实也是因为"容器无关,架构无关"而带来的好的副作用.
所以,我想说的是,无论如何Spring都成不了EJB,两种完全不同的思路,EJB走的路类似于微软的那套大而全,而Spring走的则是小而精,更开放一些.

所以说即便明天Spring被别的取代了,其实也说明Spring本身的开发有问题,但是和EJB的没落进行关联,确实不是个恰当的类比,需知道,连EJB3都已经和那个被抛弃的EJB2不一个思路了.

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


要对action做单元测试,说明你的代码中,action充刺着大量本不属于action的职责,action本身是简单的,对action做测试,就是蛋疼行为,1+1=2需要测试吗?相应的包括什么service测试,dao测试,都需要个mock对象,我不否定mock。但也不是什么都用个mock。如果一个类可以自测试,我还要这些xxx注入干什么。就是因为需要xxx注入,所以项目代码一大坨,测试代也一大坨。
0 请登录后投票
论坛首页 Java企业应用版

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