|
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
时间:2008-04-28
theone 写道 用Spring的唯一理由就是:Spring是一站式的解决方案。
使用EXT的理由也是类似的,我今天找了很多jquery/mootools plugin,可是每个plugin都不能包括我所需要的所有功能。找了一圈还是回到EXT。 一站式有什么不好~ |
|
| 返回顶楼 | |
|
时间:2008-04-28
Spring作为粘合剂介入J2EE开发其实角色是相当尴尬的,而且它所谓的集合也只是为了让其它第3方的产品无缝兼容它自己Bean微容器而做的整合。难道没有了Spring,人家第3方的框架就不能工作了吗?!另外,IOC模式Bean容器在框架层次整合服务有其优势,但是对于普通的业务Bean,事无大小,没有任何界定就用Spring的Bean微容器装配的话,那就是楼主所说的,“。。臃肿的xml配置让我讨厌”了。
随着其它第3方框架自身不断完善,粘合剂的作用越来越淡化的趋势肯定是必然的。 Spring应该作为一个业务层框架介入,可惜Rod Johnson捉错了方向,Spring现在不足成为一个业务层框架,以后也估计也不会是一个业务层框架。 |
|
| 返回顶楼 | |
|
时间:2008-04-28
rain2005 写道 引用 1-离开hibernate你不用混了?
2-单例工厂?你要走回头路? 3-spring aop等同于spring secrurity?等同于transaction上使用的aop? 4-你单独拿出来用还不是依然在用spring? 5-你真的充分了解了spring remoting的好处了吗?还是就知道一个rest? 离开hibernate你不用混了,对应这个我已经不需要辩解,到目前为止还没有找到不使用它的理由 单例工厂?你要走回头路? 我是说你不用guice的前提,就算是单例工厂也没有什么不好 请老兄说是你还用spring aop做了什么 还不是依然在用spring,我的意思是不是使用spring作为系统架构。 那还请你说说spring remoting的好处?在目前我web应用间的通信使用REST更为自然,更跨平台。 1-你找不到理由,不意味着别人也找不到 2-你使用guice提供的ioc服务,跟spring提供的ioc有何区别?都是ioc而已,你觉得使用guice的为你理由可能是觉得它给你的使用ioc的tip受你欢迎,可本质上,你只是在找一个ioc容器而已,这跟用spring和guice还是我自己编码inject没本质上的区别; 如果你觉得singleton factory挺好,你用就是了,没有人阻拦你 3-我用spring aop做的多了,但我没有必要一一为你列举 4-spring的template给你的是一种理念,跟你用不用这个framework没关系,而且,不要说用spring作系统架构,这话我听着别扭 5-你觉得用rest自然,并不意味着rest就是唯一的远程方案,如果你用心点儿,多涉猎一点儿,你会发现,所以的远程方案实际都tmd一个味儿,spring的exporter+proxy的方式,完全可以退而广之到ejb3,web service,不信你试试 我说这些话不是跟你争论spring好还是什么其他framework强, 本质上来说,解决问题才是最主要的,如果你喜欢白猫,那就抱一只白猫,可不要忘了,你喜欢的是猫,不是它的颜色,或许那天你看白猫不爽,又去抱回一只蓝猫也说不准啊,哈哈 |
|
| 返回顶楼 | |
|
时间:2008-04-28
fujohnwang 写道 5-你真的充分了解了spring remoting的好处了吗?还是就知道一个rest? spring remoting 有什么好处,还请指教! rest是一个概念不是一个产品,怎么和spring remoting比较?spring的rest在哪里? |
|
| 返回顶楼 | |
|
时间:2008-04-28
不是说spring remoting有什么好处,而是你从spring remoting能够看到什么
实际上,所以的remoting方案,几乎都是在service端设立一个专门expose service的角色负责处理client端的request调用,而为了能够让client端以透明的方式来访问remote端的service,也几乎都是通过一个proxy对象来屏蔽service访问到底是本地访问还是远程访问。 你看你能不能从Spring remoting推演出这么一套东西?!你再对比一下EJB,WS之类处理remoting的方式,又有没有是曾相识的感觉?!实际上,可能具体实现细节上或者使用的技术上有差异,但我认为都是一条路子走下来的。 当然,或许我也是孤陋,如果有什么不对的地方,let me know,please(以免我误导人) |
|
| 返回顶楼 | |
|
时间:2008-04-28
看来你还真是孤漏寡闻,看了REST之后你后明白很多!
|
|
| 返回顶楼 | |
|
时间:2008-04-28
呵呵,I said let me know ,please, u say nothing ,in fact
:-) |
|
| 返回顶楼 | |
|
时间:2008-04-28
spring确实越来越庞大
而且新的2。5。3使用到了java6的类了,如果要跟着跑很困难,毕竟应用服务器跟不上 |
|
| 返回顶楼 | |
|
时间:2008-04-28
theone 写道 fangshun 写道 不过spring倒是还有很一个问题很是值得思考,spring是interface21的私有产品,如果有一天spring的新发行版本也像ext那样改一下许可,那可够大家受的!
那老版本的LGPL协议改不了,你可以继续用老版本,还可以自己修改老版本的代码再发布出去。 没有你说的那么简单,何况spring处于整个j2ee平台的枢纽位置! theone 写道 用Spring的唯一理由就是:Spring是一站式的解决方案。 spring和j2ee规范比起来,后者应该才能称得上是一站式解决方案 spring只是类比于ejb的管理式框架,而且它的mvc并不怎么有优势,它的web请求->service对象之间通过线程本地方式对请求资源的绑定能体现出有状态方式的管理,其他均表现出无状态特性,和seam的各层上下文相互调度比起来就太粗糙了,总体感觉spring的解决方案是简单,直观,灵活,但是又缺乏层次之间资源调度的平滑转换,各个层次之间的交互基本是接口碰接口,资源的传递基本需要转换成参数进行传递,而无法高效的利用各层上下文所具有的状态能力! spring aop 简直就是魔法师,通过它我可以无缝的在各层转换模型的实例类型,进行扩展调用,屏蔽不必要的显示转换。让代码表现的更有张力,让业务模型变得更突出! |
|
| 返回顶楼 | |
|
时间:2008-04-28
rain2005 写道 这两天看了一下Hibernate实战第二版,从书中的例子可以我想我可以放弃spring了。
我们需要spring什么呢? 1.事务和资源管理 大部分人需要的。但是有了hibernate的thread范围的session Context,一个filter就搞定了事务与资源问题。所以我不需要Spring的事务和资源管理 2.IOC IOC。是的它很好,很强大。但是臃肿的xml配置让我讨厌。用Guice更简单。在不行就用单例工厂把。 3.Aop 事务Aop我已经不需要了。spring安全框架么?对不起你太复杂了,没有必要。 4。模板类 对了你提供了很多模板类,不错。不过我拿出来单独使用也是可以的。 5.远程调用 试试REST把。 大家也谈谈自己使用spring的感受把! 1、为什么要自己定制filter呢,你的filter有Spring的声明性事务管理强大么? Spring可以配置具体的Exception来回滚事务,支持正则表达式和AspectJ表达式, EJB都无法比拟,你能轻松实现这样一个filter么? 2、Guice的确不错,但只是一个单纯的IOC。并且Spring2.5可以同样使用Annotation简化配置。 3、AOP莫非你又要想写一堆Filter来搞定。。。 5、REST好倒是好,MVC已根深蒂固,说REST就能REST么,那么容易转变么?貌似还没见太出众的支持 REST java框架出来。况且Spring也打算开始REST. |
|
| 返回顶楼 | |








