和一个朋友的聊天，他比较排斥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:
想半年呆在家里 一边搞好生产 一边搞建设 

好长啊，我要慢慢读。有朋友问过同样的问题，就我粗浅的理解还是有自信说服他地。

Spring的配置是比较复杂啊，感觉没有自己写代码清晰，大家怎么认识？

无所谓对错，设计是要讲究上下文，与特定场景
如果说在Action里处理业务逻辑，那么事务是可以放在Action中begin/commit，否则，单独在业务服务层引用一个事务管理。至于事务是采用编程式还是声明式，我还是比较喜欢this.beginTrans(),this.CommitTrans()，自己底层实现可配置事务类型。

ps: 巨龙？厦门巨龙？

认真看完了全部对话。
其实有个问题很痛苦，我在一个项目中也是按照楼主那朋友那样设计的。
设计了一个事物Action，只要继承就能取道事务，同时也提供了事务Helper类，本来是建议大家根据实际情况使用那个更好的。结果是所有人写得代码都继承TransAction， 痛苦的不行。这是我在2005年设计的一个构架遇见得问题。本来我也是觉得Spring在我们的项目中可能并不合适，或者说，并不需要这样的东东。没办法，后来只好引入了。后面也同样带来有类似的问题，我写了个DEMO，大家也是不分情况照着去做。但是有SPring，接藕还容易些。

至于网络上，太多轻言某某带来的成功，也是向来报有怀疑态度。
我不知道是否是由于我们自己的开发太落后的问题，反正我自己的项目经验来看我没看出来，改用webwork会比struts带来很大的好处没看出来（好处不是没有，只是觉得在我们的项目中体现出的好处有限）。

    在平常工作中，我发现对Spring持反面意见的人还是挺多的，他们的一个重要论据就是EJB曾经也这么热过，曾经对EJB有着宗教般狂热的人，在风沙已止，销烟已散后，才发现原来自己被堪称完美地愚弄了一回。
    所以当他们发现Spring又热起来时，由于他们原来爱得太深刻，痛得太彻底。就象《穆斯林的葬礼》的主人公新月一样，在经历过一次轰轰烈烈的失败爱情之后，已经失去了爱的能力，在自己的周围建起了一堵围墙，不许任何东西靠近，以避免再次的伤害。
    这在一定程度上比起原来的盲从是一种进步，毕竟经过风雨的洗礼小孩子长大了，成熟了，但是是否而正因为我们的成熟而散失了很多美的体验呢。
   
    还是林志眩《单身情歌》中的那两句歌词不错：爱要越错越勇 爱要肯定执着：），如果你要恨Spring，应该要在学习透切之后，就象Rod Johnson，他批判EJB 是在理解透彻EJB之后，甚至他的Spring还从EJB中学习了很多好的内容，如声明事务的那几个事务管理属性和EJB的简直一样。

对自己没有用过的东西产生置疑是很正常的现象。

有什么必要非要说服人家呢？自己用好spring框架不就得了吗？

我就希望你们大家都别用spring，都自己手工搞定对象之间的依赖关系，手工搞定事务控制，手工搞定数据库访问层，嘿嘿想像一样那样的情景，该是多么幸灾乐祸啊。

碰上这种人，我就一句话，是的spring很烂，所以你千万别用spring。

  To:Robbin
  呵呵 是啊，让一个人改变想法确实是一件不容易的事 。

哈哈，终于发现有人跟我同样的做法了。
就像robbin，我就经常告诉别人spring很烂，怀疑就不要用了