和一个朋友的聊天，他比较排斥Spring
此处省去废话100行：）
Unknow---- says:
你可以从spring的价值来考虑下..我对spring在项目的应用所带来的价值还是有怀疑..
Stamen says:
你选Acegi做权限 很适合 我的判断是一定可以胜任行业性的系统
Stamen says:
Spring我用得越深 发现他的实用性更好 你可以花时间多了解 再做判断。
Unknow---- says:
你说来看看,spring的价值
Stamen says:
Spring 2.0对配置做了大副的简化，而且你所说的契约模式 Spring是可以实现的
Stamen says:
我觉得主要有以下几点：
Unknow---- says:
还没写完哦..
Stamen says:
1)使类充分解耦，不需硬编码的方式 设计类和类之间的关系，它带来的好处是，你可以随时替换关联者，而无需动代码；
2)由于类都在Spring容器中统一管理，为加入切面编程提供了可能，业务对象从事务，安全性，日志等代码等非业务性的代码中脱离出来，业务类更简洁 只关注业务；
3)Spring使你更加方便地使用常用企业功能，如JavaMail，Timer，远程调用，缓存，安全等，Spring使得利用这些类库得到了很大的简化，而如果你直接用这些类库，学习曲线陡峭得很多；
Stamen says:
4)Spring使测试更加容易，对于Web的应用，它提供了很多Mock测试类，无需启动Web服务
Stamen says:
5)还有很多待发现的好处...
Unknow---- says:
第一点应该是spring的最核心的价值,也是最初的价值..但这点的实用价值在我们做项目中,真的有用吗?
Stamen says:
第一点 在一般项目中实用性并不明显
Unknow---- says:
第二点,切面所带来的思想远远比现在所带来的价值大..他的价值是什么.能带来多大的价值哦
Stamen says:
它更象是框架级的东西
Unknow---- says:
第三点是有价值了
Unknow---- says:
第四点易测试,,也是看项目如何做了..
Stamen says:
我觉得 第2点是工程性项目最有价值的地方，事务，安全，日志代码的拨离 太太提高了代码生产率
Unknow---- says:
事务,其实作用不大了..
Unknow---- says:
用配置的事务,可比用写代码的麻烦了..
Stamen says:
你看看Acegi就好了，它就是将程序的访问控制剥离出来 在业务代码中根据看不看访问控制的痕迹 ，这点太伟大了。
Stamen says:
“用配置的事务,可比用写代码的麻烦了..”只能说明你对Spring不够了解
Unknow---- says:
就是安全还可以有参考的价值..但我们做业务系统,很多是在界面控制权限的..而ACEGI是在服务端控制的..
Unknow---- says:
为什么这么说?
Unknow---- says:
你用配置的事务,比写代码的,有用的价值体现在哪
Stamen says:
Spring2.0提供了简洁的事务配置，利用AspectJ来做事务，配置的简化是数量级的，你可以看看这方面的资料
Unknow---- says:
能简洁到什么程度?
Stamen says:
首先，我觉得配置不是首要问题，首要问题是业务对象只需要关心业务逻辑才是关键中的关键
Unknow---- says:
这个从思想上没错,我一直认同这点..其实这点从根本上讲就是单一职责原则,无论是分层,还是把事务,安全,日志从业务中的抽取都是体现这点.
Stamen says:
业务对象只做自己手头上的工作，自己的工作究竟如何被组织起来完成一件“大事”业务对象不用去关心，这样业务对象的逻辑就大大简化了，我举一个例子，象69年的阿波罗登月项目 ，参加的单位，组织，学校有上千个，人有11万多，上面有一个总调度人总揽全局（Spring），而各个单位只负责自己手头的事，甚至某些单位只是简单按标准做好了螺丝钉。如果没有总揽大局的协调者，那么每个单位都需要双方去协调事务，那么项目的复杂度马上不能控制了。
Unknow---- says:
但我觉的更要从实用性考虑..就像EJB一样,它所体现的思想不错,但实用性太差了,所以被市场抛弃了
Stamen says:
EJB的复杂不在于声明事务，相反声明事务是EJB最大的亮点，EJB的复杂在于它和容器捆绑太死，以至于在开发中的测试上非常困难。
Stamen says:
测试的方便性直接影响到开发的效率，Spring比之EJB最大的提升就是易测试上，其次就是使POJO可以使用声明事务
Unknow---- says:
但它的思想是体现在组件思想上..这是它的核心思想,但EJB的实现很糟糕,所以开发人员使用时,实用价值太低了.所以被抛弃了..
Unknow---- says:
而SPRING的思想就是你提到的,问题是我们在项目中使用spring,真正能带来的实用价值是多大..这点才是最关键的..
Stamen says:
不管是组件也好 POJO也好 如果它易测试 易部署 对于实际的开发和应用 负面影响倒不会太大
Unknow---- says:
就像声明式事务,在我们以前所做的业务系统中,能比我们以前的方式带来多大价值,不是指思想上.而是指实用上..
Unknow---- says:
你所提到的易测试性,也很不错,这也是我以前所总结过的.
Stamen says:
价值就是简洁代码开发 提高项目进度 这难道还是不实实在在的价值吗
Unknow---- says:
spring在实现时,考虑到了易测试性,很好..所以作者真的是实战思想家
Stamen says:
你去拿一个模块，一个自己写事务管理 一个用Spring声明事务 比较两者的代码行 两者的开发效率 就一目了然了。
Unknow---- says:
简化代码,问题是简花了多少代码,其实我们在做业务系统中,事务很少为我们项目带来麻烦..很少BUG是由事务的问题带来的..而采用基于配置的事务,必须要运行时才能测试事务的完整性吧..
Stamen says:
叫程序员去一遍一遍写没有思想的事务管理代码本身就是一种人力资源甚至是智力资源的浪费。
Unknow---- says:
而且如果我们采用统一风格的事务,我们完全可以做到在一个地方写事务控制的代码,业务逻辑不需要涉及事务,可能更简单..
Stamen says:
一个地方写事务控制的代码？？？不太现实
Unknow---- says:
可以了..其实我们的业务系统很简单了.都是在action控制事务了..我们在commonaction中控制就可以了
Unknow---- says:
其实内可以考虑配置型事务真正实用的价值所在..
Stamen says:
哈哈 Action是展现层 展现层去干涉业务，你会被人踢的
Unknow---- says:
我的理解跟你不一样..事务不是简单的指数据库的事务哦.
Stamen says:
不管怎么样 事务都是业务层的负责 你把在扩展到展现层 是比较严重的设计缺陷
Stamen says:
假设Service还有一个C/S应用需要调用 ，或者一个WAP应用需要调用 Service层还能够通用吗
Unknow---- says:
举个例子吧.用户注册的,用户注册成功,必须要在数据库中插入用户记录和日志记录,还有在每天注册人数增加一,还要发送邮件,如果有一步出错,都要退回,这时候用配置的事务就很难解决了
Stamen says:
用Spring绝对可以解决你这个需求
Unknow---- says:
我觉的我们开发人员有一个毛病,就是想很多不存在的需求,所以导致设计偏向了.如果我们只把握最核心的需求,那我们的设计就很简单..所以我觉的设计简单,要比设计可扩展性更要考虑
Unknow---- says:
我注册失败后,还要让当天注册人数减一..用spring如何解决
Stamen says:
设计简单要事先满足一定的规范，象你让事务在Action中控制 这就有点过了
Unknow---- says:
其实你要看action它真正体现的是什么了,我觉的它是事务的发起者和结束者.所以在action中去简化它..就变的容易了..
Stamen says:
做一个ThrowableAdvice就可以了，当发现用户注册失败异常时，用户注册人数减一
Unknow---- says:
做切面时,你能调用HttpSession吗
Unknow---- says:
当天注册人数,我可能要操作用户的session,如何在你的ThrowableAdvice做呢
Stamen says:
Action是业务服务的调用者，但不是事务控制的管理者 事务是业务的范畴
Unknow---- says:
如果做一个平台,我会采用基于配置的事务,如果我像平时做业务系统,当然要怎么做最简单就怎么做了.
Stamen says:
让ThrowableAdvice实现ApplicationContextAware 就可以获取Session了。
Unknow---- says:
这只是个例子.我觉的spring的思想不错,但很多东西都是刚开始,还没完善,所以如果现在用这些特性,可能把本来很简单的项目弄的很复杂..这是我们做业务系统必须要考虑的..你可以想想用spring做我们以前的业务系统,能不能带来你所说的价值..
Stamen says:
不会错，简单的业务系统怎么做都可以 你甚至可以只用JSP实现所有功能，关键是为什么大师们都坚持Service和View层要解耦 他们的经验和理解力 已经实践经验都是在我们之上很多倍的
Unknow---- says:
还有一点你要考虑的,国内的IT环境跟国外的不一样.我觉的这点就带来很大的影响了
Unknow---- says:
你可以考虑下我们以前的业务系统和采用spring后,你可以对比下..
Stamen says:
一个东西要用好它就先要搞透它 否则不但得不到简化 可以带来更多坏的影响，就象F22性能虽好 但开不来还如拿大刀
Unknow---- says:
很多开发人员都是国外人员提什么技术,国外人员说好,国内的就跟风,我觉的很多开发人员缺乏对技术的鉴证性,就是这个新技术能不能为项目带来生产率和质量的提高,这是最关键的.鉴证性如何考虑呢?有一点很重要,就是实用性,在项目中去实践..
Stamen says:
对，国内的开发人员半调儿的太多 稍微培训一下就上路 在学校学的也都是过时的东西 因为没有自己的思想 跟风就比较严重，所以才会有EJB热
Unknow---- says:
是啊..所以如果一个技术没转眼透,对技术的理解不透彻,都可以对使用这个技术带来错误的判断.也许我犯了这个错误,但至少我还没看到那个人能真正说出在他们的项目中,用spring带来了生产率和质量的提高..
Stamen says:
不对 Spring已经为项目带来了生产率的提高 这是用过Spring的开发人员的普遍感受 Spring是从劳动中来到劳动中去的框架 而非EJB这种皇家血统的
Unknow---- says:
是啊.你说的没错,那是国外..国内呢..你要看你周围的.而不是从网络上别人这么说哦
Unknow---- says:
像EJB刚兴起的时候也是这么说的哦
Stamen says:
我自己就觉得Spring让我编码轻松了不少 以前写事务代码真是太单调了
Unknow---- says:
国内很多人说用SPRING为项目带来了生产率的提高,但很多都是假冒了,没有真正去思考,是不是真的带来了,这点在网上特别普遍..
Stamen says:
用Spring做开发的项目是非常多的 Xxx公司这边都用Spring，我原来在yyy公司做的几个项目也是用Spring
Unknow---- says:
写代码单调,这不是理由哦. 是要类比以前写的,是不是真的比以前写代码写的更快了..你想想以前写新增用户的事务逻辑,也就两行代码,短短的两句..而用spring呢.你要配置两行吧.
Stamen says:
事务代码都不用考虑了 10分事去了2分 怎么不省事
Unknow---- says:
但我问了那些yyy公司的人.有咨询过他们,他们说不错,但我问到真正的点子上的时候,却上来.都觉的跟以前比,其实真正没有带来多大的价值了
Unknow---- says:
但你要配置哦..你在代码中不写,但在配置文件中要配置哦.
Unknow---- says:
像小翁,张崇镇,都是在yyy公司最早使用的,也是使用的最多的..我都问过他们..
Stamen says:
就象某个人 由于前列腺 一天上班要上厕所20次 现成前列腺好了 晚上回来上一次就行 难道还能不轻松吗
Unknow---- says:
但我在业务系统也可以做到只写一处就可以了..很简单.连配置文件都不用配置,如果出错了,我只看那处代码就行了..错误信息打印的都很清楚,而用配置呢,追踪BUG可能不如原始方式好吧..而且可能配置写错了,如果不太理解框架的话,还可能因为配置错了,让你找半天的BUG,这都是基于配置的缺陷.
Stamen says:
那就是看配置的量和代码的量哪个大，事务要获取资源 ，做事务提供 回滚 释放资源 代码加起来没有20行恐怕搞不定，但配置有多少行，用一个parent事务<bean> 事务<bean>继承的方式配置，你只要为一个方法声明事务的属性就可以了，顶多1行
Stamen says:
我刚才说过 你的设计是不合理的
Stamen says:
是为了达到目标不择手段的那种
Unknow---- says:
代码量不大了.业务系统已经简化事务代码了...不像你说的,还要回滚处理,那太原始了.
Stamen says:
你不要去问别人 自己做一个试试就OK了 当然刚开始会觉得比较麻烦 用多了就不会了 毕竟学一个东西是要代价的
Unknow---- says:
这可能是我的设计理念导致的..就是设计一定要简单..如果我用这种方式,就可以做好业务系统,而且这种方式在我做过的业务系统中都很适用,为什么不采用呢,难道还要考虑像国外那么复杂的IT环境,或者考虑我的业务系统可能慢慢变成像电信银行这么大的系统吗? 我觉的这种是过度考虑需求.
Stamen says:
之所以觉得不太好 我觉得很大部分原因是认识不够 还有就是固定思维
Stamen says:
那我问你 如果展现不是一种方式 用C/S 有WAP，你Service能通过吗，是不是事务代码都要重写，不是多种展现 ，你哪天觉得Struts到尽头了，换个
Stamen says:
Webwork ,方便吗？
Unknow---- says:
webwork是一样的..
Stamen says:
如果设计不能提供这种起码的灵活性 还有设计干什么
Unknow---- says:
我觉的你考虑的过度了..很多开发人员有个问题,就是过分考虑需求..
Unknow---- says:
设计都是有上下文的.. 你觉的做业务系统,设计最主要考虑的角度是什么? 不是灵活性或者可扩展性吧..
Stamen says:
好 ，先假不存在多展现和切换展现端技术的问题，你这样设计 能够允许分层开发吗？
Unknow---- says:
不要片面的追求完美的设计,我觉的做业务系统最主要考虑的就是功能性和简单行.
Unknow---- says:
可以允许分层开发啊.这不会为分层开发带来任何问题啊..
Stamen says:
你说的这些也是要保证 ，但凡事有度
Stamen says:
事务的逻辑是业务上还是展现上的？
Unknow---- says:
问题我们做的架构,可以让开发人员不需要考虑事务了啊..因为底层已经都实现这种服务了
Stamen says:
你的事务都是一个Action方法一个事务吗？
Unknow---- says:
假如就在commonAction中实现了.开发人员继承一个action就可以获得事务服务了
Unknow---- says:
是啊..
Stamen says:
不跟你玩了
Stamen says:
一个Action方法一个事务，你这个大头
Stamen is searching for:
我要找我笑掉的大牙了
MSN Search says:
We couldn't find any sites containing "我要找我笑掉的大牙了 ". Try using different search words.
Unknow---- says:
呵..这就是我的架构设计思路..你可以考虑下..想想我为什么这么做..而不是一定要做到思想的完美无缺性..我觉的我实践的体会就是设计一定不要考虑做到设计的完美性.
Stamen says:
你也走极端了
Unknow---- says:
哈....这都是来源于实践中的设计.而不是凭空捏造的.当然都有来源了..
Stamen says:
那只能说我们见过的项目多太简单了
Unknow---- says:
也许吧..因为我把设计的简单化看的太重了,就是我的设计一定要保证生产率和质量的提高,我的最高设计原则就是这个.其他的不考虑.
Stamen says:
我现在的项目就不允许这种粗细度
Unknow---- says:
对哦..所以我就跟你说我们的环境跟国外的IT环境不一样哦..
Unknow---- says:
那一天有空,你可以把你的项目说给我听听..也许我会改变我的想法.
Stamen says:
我说个我现在项目的一个现实需求吧
Unknow---- says:
可以啊
Stamen says:
用户升级产品事务失败，将信息记录下来，并发Mail给管理员，
这里有三个业务，升级产品事务 记录场景数据事务 发Mail业务 但都通过一个Action方法处理
Unknow---- says:
如果记录场景数据失败,或者发email失败呢..
Stamen says:
框架的简单是在能够满足业务的需求的灵活性上来做，它有一个基础 ，而不是不择手段的简化 ，否则就象60年代的大炼钢铁 有产量没有质量了。
Unknow---- says:
但你要考虑国内的软件背景,一个业务系统软件究竟能用多久..不同的上下文,就有不同的设计..
Stamen says:
productSerivce.upgrade(product);
Stamen says:
try{
productSerivce.upgrade(product);
}catch( RuntimeException e)
{
productService.recordFailLog( product);
mailSender.send( mail);
}
Unknow---- says:
而且不是没有质量,我设计的最高原则就是软件生产率和质量的提高..
Unknow---- says:
然后呢
Stamen says:
你上面提的小小需求你的框架都满足不了了 还说质量和生产率 质量和生产率是要做对事的前提下
Unknow---- says:
错了哦..设计是依赖上下文的,老大..如果需求是这样的,当然设计要去改变了,难道一套设计就能走天下嘛....
Stamen says:
你的设计是要通用的，又不是只给一个项目用
Stamen says:
给一个项目用 就直接写JSP 也是可以的
Unknow---- says:
那你也极端了哦.. 这种我的架构也是可以做的..
Unknow---- says:
spring如何实现呢
Stamen says:
别的先不说，有两个解决思想是一定有问题的：
1)事务在Action层控制
２）事务粒度为一个请求
Unknow---- says:
那你说说问题的所在吧
Stamen says:
上面不都说了 笨
Unknow---- says:
没有吧..我怎么没发现啊..
Stamen says:
笨 笨 笨
Unknow---- says:
问题还是你怎么看待action了..
Unknow---- says:
那你用spring怎么解决
Stamen says:
Action负责两部分的功能 ：
1) 页面流程控制 ，如失败转向哪儿 失败转向哪儿 等；
2) 业务流程控制 ，如上面我举的那个例子，成功升级后 如果处理 升级失败后 如果处理等
Unknow---- says:
你说的没错了..你的那些代码应该叫做应用组织逻辑..
Unknow---- says:
它不属于核心的业务逻辑..如果你把action来作为应用逻辑组成层的话.也是可以做到的
Stamen says:
Action并不是完全不负责业务 ，但它控制的业务逻辑是粗粒度的 是业务流程层面上的，而非事务流程层面
Unknow---- says:
当然了..spring的基于配置事务是很用的,我在青鸟中所教的架构,就是用spring的事务,当时也提到一个spring唯一能看到实用性的价值
Stamen says:
不说其实的，这一点已经很不错了
Stamen says:
其他
Stamen says:
你去给你们领导吹吹风吧，我到时给你们培训Spring
Unknow---- says:
呵..就像我说的上下文一样,如果上下文不一样,设计真的不一样,就像你提的,我在北大青鸟就是用spring解决的.但不用spring也是可以解决的.
Unknow---- says:
可以啊..没问题啊..不过要讲实用的..
Stamen says:
嗯 也是有一定的道理 ，不过我不相信电力的业务会那么简单
Unknow---- says:
不过讲下设计思想更好了
Unknow---- says:
电力业务没你想的复杂了.可能更简单..
Stamen says:
Xxx公司的开发人员水平还不太高 目前更突出的问题是开发实现上 设计思想和你聊就OK了
Stamen says:
如果事务是请求级别的 那就OK
Stamen says:
不过没有1K 不去讲哦
Unknow---- says:
是啊..但我是希望两个都有了,多讲下思想,对他们改变思想比较好..希望他们能听到好的思想,可以在项目中去体会..
Unknow---- says:
我帮你提下..
Unknow---- says:
不过不知道行不行哦.因为我以前就提过,但没成功..
Stamen says:
不要紧 可以随便说 我不一定有空
Stamen says:
想半年呆在家里 一边搞好生产 一边搞建设
49 楼 rockjava 2006-11-04 很无聊的话题，有意思吗？有价值吗？ 50 楼 dwangel 2006-11-04 wobuzhi 写道我就是那个所谓的朋友,看了大家的反馈,感觉收获蛮多的.不过,我想纠正下,其实我在04年就自己使用spring了,而且04年还建议过公司使用SPRING.而不像有些人想象的没使用过.:)
其实,在我现在看的书中,有两本是SPRING的书,你说我是排斥SPRING吗? 我从来不排斥,相反我很喜欢SPRING的思想,但是要让我在项目中使用SPRING,我没有足够的理由说服自己,周围的用SPRING的朋友也没有足够的理由,我也曾在网上寻找过这个答案,可惜没有找到一个人专门来阐述SPRING在国内项目中所带来的价值(不是写所谓的AOP,IOC,基于配置的事务等),而是带来看的着摸的到的价值,而不是仅仅说说而已的价值.我想hibernate框架为项目所带来的价值,大家在使用时都深刻体会到了吧,即使你只是使用hibernate来替代JDBC这个最基本的功能.但SPRING呢? 它为项目所带来的价值真的像国内很多人说的那样多吗?
我觉的我设计时最高的设计指导原则就是软件生产率和软件质量的提高,而不是所谓的可扩展性,灵活性,代码优雅,基于配置,面向切面,IOC等.我们一定要时时刻刻的牢记我们做软件的目的,这就足够了.而不是用SPRING,我就一定能为我的项目带来更多的价值,有时候大家能静下来反省下会更好,国内从来不缺少优秀的实践者,但往往缺少思考者.
那些EJB兴起的时候就说EJB好,HIBERNATE兴起的时候就说HIBERNATE好,SPRING兴起的时候就说SPRING好,这种人在国内太多了,为什么每个时期的流行思想都不是国内人提出来的呢? 不要仅仅实践实践再实践,为思考多留点时间吧..
hehe
Rod Johnson自己在《J2ee 设计开发编程指南》里都是主张 问题驱动而不是技术驱动。
Spring的框架，应该说是针对某一类问题提供了一套解决方法。但是，同样的问题并非不能用其他方法解决。
应该说，使用spring，可以减少一些自己设计编写工具并且整合的工作量。
如果有一群同样技术水平，配合很默契的工程师，使用不使用spring，其实差别不大。
spring就像外面卖的工具包，螺丝刀钳子之类的都有。家用维修基本够了。一般人拿过来就能用。
但是，对一些专门工业的人来说，比如修汽车，他们用的工具从尺寸上，精细度上可能就不一样。有时候用惯了自己手里的工具，拿个大众化的工具，即使能干同样的事情，也觉得不习惯。甚至有人更喜欢自己定制工具，更顺手，更省力（对他个人，但不一定适合别人）。 51 楼 hongliang 2006-11-04 完全没有意义的讨论。没有最好的library or framework，只有最合适的，哪个你觉得用着爽你就用哪个。我最初也觉得WebWork+Spring+Hibernate+Freemarker狠爽，现在把WebWork和Spring都踢走叻，因为用着多叻就觉得不爽叻，用起来太麻烦，索性自己写叻个框架，现在这个框架正用在公司的新产品中，不仅解决叻狠多以前Spring+Webwork的麻烦事，而且最重要的是大家都觉得用着狠爽，对我们自己的胃口。
下一步我要把Hibernate和Freemarker踢走，因为现在觉得它们俩个也碍事叻。
每个程序员都有自己的一套编程方式，有人喜欢麻烦点，有人喜欢直接点，有人喜欢规范点（如JSF拥蹩），有人喜欢灵活点。没有谁对谁错，自己用着爽就行叻。
就跟房子/车子/妻子/孩子一样，自己觉得好的那tmd就是好的！:D 52 楼 daquan198163 2006-11-04 partech 写道daquan198163 写道Spring可以让我们这些菜鸟在不知不觉中享受AOP的好处，为什么要去用AspectJ做同样的事情呢，为了出去说自己用过AOP时底气更足？：）
还有Spring对web层和持久层框架的整合、简化异常处理、简化单元测试。。。如此多的好处一站式提供
AspectJ的使用要比Spring的配置简洁得多。使用Spring的AOP并不会不知不觉，原理是相同的。
还有你说的整合问题，Web没用过，没有发言权。同持久层的整合是鸡肋，有时还不得不直接访问。
简化异常处理是啥意思？单元测试还需要启动Spring麽？
这里说的单元测试，严格讲应该叫“集成单元测试”了，确实会启动Spring容器，参见江南白衣的幼学琼林--Spring下的单元测试要点
Spring对web层框架的整合：struts/ww/jsf可以随意切换，Equinox（同名，但不是那个Eclipse的项目）项目充分展示了这种能力，还有整合hibernate/iBATIS
简化异常处理：Spring提供了一种设计巧妙的异常处理机制，可以把底层抛的异常转换成runtime型的，使得应用代码及其简单，最明显的例子就是，虽然我在用着Hibernate，但我的DAO里根本没有Hibernate的异常，甚至没有import任何Hibernate的类；
现在人都很懒惰，程序员尤其懒惰而且据称是种美德，Spring提供了一站式解决方案而且解决的还挺优雅，所以能流行，那个AspectJ虽然某方面很厉害，但是他解决的问题太单一了，我这样的懒人一般不愿意投入精力去学
而且AspectJ不是已经合并到Spring2.0了吗，咱们还在这里争什么呢？ 53 楼 marshal402 2006-11-06 我觉得可以这么理解“框架”的概念：它是项目中一系列规约的具体实现，是规约的执行者。实际情况不同（使用者、项目环境），所产生的规约不可能有完全一致的要素。对于一个现成的通用的框架，有人觉得好有人觉得坏，我觉得问题应该出于此。当然有一点是一致的，那就是规约的提出，是在结合实际情况的基础上，对实践经验的总结和提升。这一点使我们不能去跟风。反过来说，一个优秀的通用的规约，对实践的指导意义也是重大的。当然，前提是你必须足够理解这个规约。如果从规约的每一个细节去讨论其是否适合应用到自己的实践，也许永远不可能满足。这就得根据实际经验和项目的情况，选择是否使用或使用什么框架了，这跟框架本身并不矛盾。 54 楼 partech 2006-11-06 daquan198163 写道这里说的单元测试，严格讲应该叫“集成单元测试”了，确实会启动Spring容器，参见江南白衣的幼学琼林--Spring下的单元测试要点
Spring对web层框架的整合：struts/ww/jsf可以随意切换，Equinox（同名，但不是那个Eclipse的项目）项目充分展示了这种能力，还有整合hibernate/iBATIS
简化异常处理：Spring提供了一种设计巧妙的异常处理机制，可以把底层抛的异常转换成runtime型的，使得应用代码及其简单，最明显的例子就是，虽然我在用着Hibernate，但我的DAO里根本没有Hibernate的异常，甚至没有import任何Hibernate的类；
现在人都很懒惰，程序员尤其懒惰而且据称是种美德，Spring提供了一站式解决方案而且解决的还挺优雅，所以能流行，那个AspectJ虽然某方面很厉害，但是他解决的问题太单一了，我这样的懒人一般不愿意投入精力去学
而且AspectJ不是已经合并到Spring2.0了吗，咱们还在这里争什么呢？
因为使用了Spring，所以需要他的测试支持，自己引入的问题，当然要自己解决。但是如果不用Sping呢？
任意切换WEB，听起来蛮不错，有实际需求么？
简化异常处理：赫赫，这个正是Aspect的长项阿，用AspectJ来实现，就是个一般问题，不需要“巧妙的设计”。
关于AspectJ的使用，我想问题就在于目前的使用太低级，太玩具，完全没有释放应有的威力。
如果，我说AspectJ可以全程的应用在程序中，你信么？
不仅如此，Aspect可以应用于整个开发过程的始终，从需求到发布，你信么？
Aspect的思想可以用以支持定义开发过程，你信么？
55 楼 robbin 2006-11-06 partech 写道daquan198163 写道这里说的单元测试，严格讲应该叫“集成单元测试”了，确实会启动Spring容器，参见江南白衣的幼学琼林--Spring下的单元测试要点
Spring对web层框架的整合：struts/ww/jsf可以随意切换，Equinox（同名，但不是那个Eclipse的项目）项目充分展示了这种能力，还有整合hibernate/iBATIS
简化异常处理：Spring提供了一种设计巧妙的异常处理机制，可以把底层抛的异常转换成runtime型的，使得应用代码及其简单，最明显的例子就是，虽然我在用着Hibernate，但我的DAO里根本没有Hibernate的异常，甚至没有import任何Hibernate的类；
现在人都很懒惰，程序员尤其懒惰而且据称是种美德，Spring提供了一站式解决方案而且解决的还挺优雅，所以能流行，那个AspectJ虽然某方面很厉害，但是他解决的问题太单一了，我这样的懒人一般不愿意投入精力去学
而且AspectJ不是已经合并到Spring2.0了吗，咱们还在这里争什么呢？
因为使用了Spring，所以需要他的测试支持，自己引入的问题，当然要自己解决。但是如果不用Sping呢？
任意切换WEB，听起来蛮不错，但有什么实际需求么？
简化异常处理：赫赫，这个正是Aspect的长项阿，用AspectJ来实现，就是个一般问题，不需要“巧妙的设计”。
关于AspectJ的使用，我想问题就在于目前的使用太低级，太玩具，完全没有释放应有的威力。
如果，我说AspectJ可以全程的应用在程序中，你信么？
不仅如此，Aspect可以应用于整个开发过程的始终，从需求到发布，你信么？
Aspect的思想可以用以支持定义开发过程，你信么？
这我到完全相信。webwork其实就是一个用AOP作为底层框架从而搭建起来的一个web框架。我也看过Richard Oberg的几篇blog，说完全那AOP来实现domain object，听起来挺不错。
spring其实是反过来的，他是用IoC来实现AOP的，spring的优势在于集成了一堆功能进来了，你拿来就可以用了，就是所谓的一站式。
如果有人基于AspectJ做了这样一个一站式的full-stack框架，我也会有兴趣钻研一下的。
56 楼 koenhuang 2006-11-06 robbin 写道对自己没有用过的东西产生置疑是很正常的现象。
有什么必要非要说服人家呢？自己用好spring框架不就得了吗？
我就希望你们大家都别用spring，都自己手工搞定对象之间的依赖关系，手工搞定事务控制，手工搞定数据库访问层，嘿嘿想像一样那样的情景，该是多么幸灾乐祸啊。
碰上这种人，我就一句话，是的spring很烂，所以你千万别用spring。
说的太好了，哈哈！ 57 楼 daquan198163 2006-11-06 partech 写道daquan198163 写道这里说的单元测试，严格讲应该叫“集成单元测试”了，确实会启动Spring容器，参见江南白衣的幼学琼林--Spring下的单元测试要点
Spring对web层框架的整合：struts/ww/jsf可以随意切换，Equinox（同名，但不是那个Eclipse的项目）项目充分展示了这种能力，还有整合hibernate/iBATIS
简化异常处理：Spring提供了一种设计巧妙的异常处理机制，可以把底层抛的异常转换成runtime型的，使得应用代码及其简单，最明显的例子就是，虽然我在用着Hibernate，但我的DAO里根本没有Hibernate的异常，甚至没有import任何Hibernate的类；
现在人都很懒惰，程序员尤其懒惰而且据称是种美德，Spring提供了一站式解决方案而且解决的还挺优雅，所以能流行，那个AspectJ虽然某方面很厉害，但是他解决的问题太单一了，我这样的懒人一般不愿意投入精力去学
而且AspectJ不是已经合并到Spring2.0了吗，咱们还在这里争什么呢？
因为使用了Spring，所以需要他的测试支持，自己引入的问题，当然要自己解决。但是如果不用Sping呢？
任意切换WEB，听起来蛮不错，有实际需求么？
简化异常处理：赫赫，这个正是Aspect的长项阿，用AspectJ来实现，就是个一般问题，不需要“巧妙的设计”。
关于AspectJ的使用，我想问题就在于目前的使用太低级，太玩具，完全没有释放应有的威力。
如果，我说AspectJ可以全程的应用在程序中，你信么？
不仅如此，Aspect可以应用于整个开发过程的始终，从需求到发布，你信么？
Aspect的思想可以用以支持定义开发过程，你信么？
嗯，看来我小看AspectJ了，不过上面两点不能同意
用Sping是为了方便集成测试的，比如每个测试结束时自动回滚事务（免得清理现场）、对ut的自动依赖注入、OpenSessionInTest
都是很实用的功能，而且这些问题也不是Spring自己制造出来自己解决
任意切换WEB：我的意思是技术选型时自由。
另外你说的
“如果，我说AspectJ可以全程的应用在程序中，你信么？
不仅如此，Aspect可以应用于整个开发过程的始终，从需求到发布，你信么？”
还不太了解AspectJ，请教一下：这种全程使用AspectJ也能做到像Spring一样高度一致、非侵入吗？（代码里基本不出现SpringAPI、定义任何东西都是<bean class="xx.xx"） 58 楼 partech 2006-11-06 daquan198163 写道嗯，看来我小看AspectJ了，不过上面两点不能同意
用Sping是为了方便集成测试的，比如每个测试结束时自动回滚事务（免得清理现场）、对ut的自动依赖注入、OpenSessionInTest
都是很实用的功能，而且这些问题也不是Spring自己制造出来自己解决
任意切换WEB：我的意思是技术选型时自由。
另外你说的
“如果，我说AspectJ可以全程的应用在程序中，你信么？
不仅如此，Aspect可以应用于整个开发过程的始终，从需求到发布，你信么？”
还不太了解AspectJ，请教一下：这种全程使用AspectJ也能做到像Spring一样高度一致、非侵入吗？（代码里基本不出现SpringAPI、定义任何东西都是<bean class="xx.xx"）
回滚事务，在父类的teardown中写一句transaction.rollback很困难么？
通过Aspect也可以自动注入阿，甚至配置文件都不需要。
说到技术选型，选取不同的WEB框架，我看不出同后面service层有多大关系。
AspectJ是对Java语言的一种扩展，俺不知道如何同Spring这样的框架比较。两者不是同类东西啊。
全程应用AspectJ,需要对编程的范式做出调整。从OO变成OO+AO。这会令人感到不舒服，就好像从PO范式转化到OO范式类似。
AO在在大家一阵热度之后，目前似乎无人问津了，我想，主要是因为在发掘了一些简单应用后，没有看到更多的领域。同时因为需要改变原有的OO思想，也需要个过程。
不过，我很看好这项技术，其必对软件开发产生深远的影响，不光局限于编程领域，持续研究中......
59 楼 shileiofchina 2006-11-07 讨论的很热烈呀！ 60 楼 winer0722 2006-11-09 我刚入行．．．以前也没用过别的一开始就用SPRING．．．不过觉得管理事务比较方便．别的也没什么感觉．．．什么IOC.AOP为啥把名字起得这么怪异哦．想不通．． 61 楼 andyao 2006-11-09 robbin 写道对自己没有用过的东西产生置疑是很正常的现象。
有什么必要非要说服人家呢？自己用好spring框架不就得了吗？
我就希望你们大家都别用spring，都自己手工搞定对象之间的依赖关系，手工搞定事务控制，手工搞定数据库访问层，嘿嘿想像一样那样的情景，该是多么幸灾乐祸啊。
碰上这种人，我就一句话，是的spring很烂，所以你千万别用spring。
这种做最好，省得做口舌之争，别人还不领情。
62 楼 andyao 2006-11-09 winer0722 写道我刚入行．．．以前也没用过别的一开始就用SPRING．．．不过觉得管理事务比较方便．别的也没什么感觉．．．什么IOC.AOP为啥把名字起得这么怪异哦．想不通．．
建议看看Rod Johnson的两本Expert one-on-one书，非常经典。
Expert One-on-One J2EE Design and Development(这本中文翻译的前无古人的乱，还是看英文)
Expert one-on-one J2EE Development without EJB(Robbin领衔翻译的，翻译的很好，一定要看) 63 楼 ahuaxuan 2006-11-29 我佩服楼主的耐心，象这么固执和偏激的人我根本就不会跟他那么多废话，让他去吧 64 楼 ponderlw 2006-11-30 关于SPRING的实际应用项目，
国内排名靠前的某知名保险公司使用的就是类SPRING的框架。
所有的新J2EE项目都基于此FRAMEWORK，差不多1年半了。
对于公司策略而言，出发点和技术人员的考虑不一定完全一致的。 65 楼 zxm_dgcstars 2006-12-01 向高手们学习！！！！！！ 66 楼 zhsx2221 2006-12-01 任何一种可以生存下来的架构都是有其精彩的地方，何必那么极端呢，采天下之长为我所用.
无论好与坏，相信对你都会是一笔财富......
自己感觉 Spring 还是不错的 ! 67 楼 Nirvana 2006-12-01 我这样告诉别人：spring很棒，为什么我不告诉你 68 楼 alexjianghl 2007-04-30 我想请一下,声明式事务的好处除了提供单例和更条理之外还有什么么,谢谢!