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

评论

32 楼 ajoo 2006-10-31  

睁眼看看spring2的这个基于namespace的自定义tag吧。实现起来麻烦无比，要写一坨一坨的乌七八糟的代码（http://www.iteye.com/topic/30964），又强迫我用恶心的xml namespace。如果要实现这么一点普通的功能就让我吭哧吭哧地干体力活，这不是一夜回到解放前了？

rod老哥为什么不学学ant，看几百年前人家是怎么作自定义tag的。

31 楼 quaff 2006-10-31  

ajoo 写道

当然是希望spring给做好了亚。properties基本就是key=value这样的结构。最自然的意义自然是bean name=bean type了。不需要神才做的出来吧？
就算spring不直接支持，也最好提供一个扩展接口，让我可以自己实现：

<include properties="myproperties.properties"/>

这不是增加了spring配置的复杂么,再说这也不是什么通用功能,今天为你的需求加个这样的功能,明天别人又有其他的需求,那spring成了什么,这个你还是用schema自己去实现吧,本来就是自己应该做的.

ajoo 写道

还有构造函数注射。知道为什么很多人反感pico么？一个原因是它自己觉得自己了不起，喋喋不休地说构造器注射比setter注射好。spring好就好在不做这种价值观的判断，setter/ctor都支持，你爱用哪个用哪个。
所以什么推荐使用的话没什么意义。很多时候应该是具体应用决定工具，而不是反过来。我需要用构造器，因为系统本来就是用构造汉书设计的。不能因为你spring推荐就改我的设计，这就叫侵入性了。
为什么我不自己实现这个功能呢？
1。比较麻烦
2。ctor autowiring是spring已经实现的功能。要求我重复实现一遍而不是重用已经做好的，好像不太合理。就是spring如果实现这个功能的时候不是重用原有的代码，而是重新再写一遍，也是bad smell。
当然，yan是可以处理这种需求的。这个功能在我们重构遗留系统的时候也发现还是有实际价值的。

如果你觉得有这个需要,可以去修改spring的源码,然后反馈回spring team,也算是对spring做点贡献

30 楼 ajoo 2006-10-31  

quaff 写道

2.总之你得写代码去解析这个properties文件,不是用java代码难道用ruby?你的java代码不依赖这个properties文件是不可能的,可能你希望spring已经写好这样的代码,你稍微配

置一下就可以用,但是你想想spring怎么可能知道你的properties的结构和意义?spring不是神,不要希望什么事情它已经给你做好了

3.你要这样的功能你自己去写一个这样的实现就行了,做好了提交给spring team.spring本来就推荐用属性去注入而不是用构造参数去注入
autowireConstructor(AClassNotRegisteredInContainer.class),这个我不知道你的yan能不能做到这么智能化,如果你的类有多个构造方法,spring怎么知道你要调用的那个构造方

法.

当然是希望spring给做好了亚。properties基本就是key=value这样的结构。最自然的意义自然是bean name=bean type了。不需要神才做的出来吧？
就算spring不直接支持，也最好提供一个扩展接口，让我可以自己实现：

<include properties="myproperties.properties"/>

还有构造函数注射。知道为什么很多人反感pico么？一个原因是它自己觉得自己了不起，喋喋不休地说构造器注射比setter注射好。spring好就好在不做这种价值观的判断，setter/ctor都支持，你爱用哪个用哪个。
所以什么推荐使用的话没什么意义。很多时候应该是具体应用决定工具，而不是反过来。我需要用构造器，因为系统本来就是用构造汉书设计的。不能因为你spring推荐就改我的设计，这就叫侵入性了。
为什么我不自己实现这个功能呢？
1。比较麻烦
2。ctor autowiring是spring已经实现的功能。要求我重复实现一遍而不是重用已经做好的，好像不太合理。就是spring如果实现这个功能的时候不是重用原有的代码，而是重新再写一遍，也是bad smell。

当然，yan是可以处理这种需求的。这个功能在我们重构遗留系统的时候也发现还是有实际价值的。

29 楼 wolfigo 2006-10-30  

dada 写道

竟然看完了。你朋友很多基本的spring和acegi的概念都没有搞清。真是不明白为什么可以对自己不了解的东西妄下断言呢？

何谓很多基本的spring和acegi的概念？spring,acegi只是为你做了N多的事情，留给你的只是一定量的配置，若干的代码量而已。有什么新东西吗？甚至可以说和ajax的产生没什么区别，唯一的好处就是其体现出来的设计思想，可有一些也是借鉴而已。

不是所有的项目都“体大如牛”的，从实用角度考虑，什么方便用什么，现在可用的东西那么多，需要什么我拿来用就是了，只要能简单，正确地表达出我某一个交易要做什么，不能做什么，与其他交易或其他系统中的业务是否发生关联，如何通讯就可以了。
重构只是一个美好的愿望，全中国有那么多的业务系统，大多数都是一个版本一个版本迭代出来的产物，你觉得上一个版本有bad smell，代码冗余，耦合极强，难道你就去重新构造这个业务系统？等你重新构造后，它的市场价值也没了，投产还有何意义？你所做的一切还有何意义？所以我觉得重构对提高个人代码素养有很大的好处，对实际的业务系统意义不大。

再来说说XP，所谓的“结对编程”，国外不晓得乍应用的，对于国内，乍应用，一个开发，一个辅助，两人轮换，可对于开发，每人都有自己的一套小九九，对于不同的需求，每人都有不同的理解，估计要两人能达到一致，恐怕就得耗费一段时间了，在开发过程中也难免不会出现意见的分歧，这样情况如何解决？老外是怎样解决的？也许你会说，每人做一个交易，一个流程，这样就不“打架”了，貌似可行，可前提是这两人得“对眼”，要么能力接近，要么关系不错，否则如何解决两人的合作关系？除非是一男一女合作。。。。。。

随便说说，欢迎讨论。。。。。另外回贴的时候，不知为何cpu占用过高，风扇时不时地在转，我用的maxthon，没开其它东西，噢，对了，开空调来的：）怀疑是文本编辑器有资源占用问题，呵呵。

28 楼 dada 2006-10-30  

竟然看完了。你朋友很多基本的spring和acegi的概念都没有搞清。真是不明白为什么可以对自己不了解的东西妄下断言呢？

27 楼 quaff 2006-10-30  

ajoo 写道

quaff 写道

ajoo 写道

偶是觉得spring的xml配置语法即使在2.0后仍然是很繁琐的。
spring的功能强大，继承了大量的第三方系统，还有acegi这类的私生子，这没得话说。理论上这是一个事实标准的胜利，是占据了先机的胜利，而不是技术上的胜利。

另外spring的灵活性也还有些疑问。

我们最近需要refactor一个遗留系统。该系统自己用property file定制了对象创建，并且在代码里面硬编码了“缺省实现类”。总而言之，是个long story。
在考虑重构这个系统的时候，没有发现spring提供温和的渐进改革方法。要用spring，似乎就不能再用现在这个property file了，也就是说，要一下子把所有用这个遗留框架的代

码彻底改掉。

还有，spring也缺乏给容器外面创建的对象注射依赖的能力。


这些都是一些很细节的缺陷了。


最后说一点。凡是说用了spring就获得了ioc的好处的人，根本就没懂ioc。IoC，或者说Dependency Injection，根本不依赖于你是否用一个IoC容器。new MyBusinessObject(new

SomeService())这就是一个IoC了。

1.spring的xml配置虽然繁琐了一些,但通过看xml的配置基本上就知道了整个系统的结构,对象与对象之间的关系,我基本上不用auto-wire.大家还是把spring的xml配置仅仅看作是

配置,其实它也是编程,特别是spring2.0使用schema配置,还点更加明显.
2.你可以在一个ApplicationContextAware的bean里面实例化你property file里面的bean,然后注册到ApplicationContext,对外面对象的注射依赖请看
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory类里面的autowireBeanProperties(Object existingBean, int autowireMode, boolean

dependencyCheck)

1。xml还是做配置最合适。一旦用作编程，往往就非常蹩脚了。我倒是还比较愿意用autowire的。如果一概manual wire，那么还要spring干啥？groovy好不好？
spring 2的schema说实话我不太理解rod为什么要引入schema这么复杂的东西。自定义tag就得要schema？ant得自定义task也不需要schema。
2。我主要是不太希望java代码依赖这个properties文件。理想情况是xml config文件里面指向这个properties文件，java代码直接读xml config文件。
3。外面对象的注射么。autowireBeanProperties还算可用吧。要是它能允许选择要注射的property名字会更实用一点。
另外，容器内没有登记的类能做contructor注射么？类似：
autowireConstructor(AClassNotRegisteredInContainer.class)


还有，对这样一个场景：
容器内很多service组件的创建需要注射appId, sessionId两个变量。
appId, sessionId这两个变量会随着程序运行的上下文不同而不同。（比如，两个线程使用两个不同的sessionId）
怎么做？莫非每个线程都要先登记appId, sessionId？还要锁定整个容器？

1.这是见仁见智的问题,你用autowire是为了节约配置代码,我不用autowire是为了看清楚bean之间的依赖关系,各有优缺点,反正spring都支持怎么选择还是靠开发者自己,即使是必

须manual wire我也会选择spring也不选groovy
如果acegi的配置全部配成autowire,那要弄清楚acegi的机制只有一个一个找java源文件去看
spring 2.0引入schema只是途径不是目的,这个东西反正是面向框架开发者的,开发复杂丢给框架开发者去搞,一般的spring用户没必要去管它,只要用它来简化配置就可以了
我觉得acegi很适合做成自定义tag的配置

2.总之你得写代码去解析这个properties文件,不是用java代码难道用ruby?你的java代码不依赖这个properties文件是不可能的,可能你希望spring已经写好这样的代码,你稍微配

置一下就可以用,但是你想想spring怎么可能知道你的properties的结构和意义?spring不是神,不要希望什么事情它已经给你做好了

3.你要这样的功能你自己去写一个这样的实现就行了,做好了提交给spring team.spring本来就推荐用属性去注入而不是用构造参数去注入
autowireConstructor(AClassNotRegisteredInContainer.class),这个我不知道你的yan能不能做到这么智能化,如果你的类有多个构造方法,spring怎么知道你要调用的那个构造方

法.

26 楼 mayu 2006-10-30  

robbin说得很好，我觉得就应该那样说如果我遇到这样的人  

25 楼 rtm 2006-10-30  

总算看到一个相同想法的人unknown

24 楼 kabbesy 2006-10-30  

人，技术人员，尤其是J2EE相关的技术人员，很需要主动的怀疑甚至否定自己，并且在外界和自己的观点之间寻找个好的平衡点。
技术人员很聪明，所以很自信，所以很喜欢钻牛角尖。
想说服别人，真难。

23 楼 [e-mail] 2006-10-30  

只看了开头,
但是连单元测试,敏捷开发的好处都怀疑的人,你跟他讲Spring,那不是对牛谈琴吗?

22 楼 ajoo 2006-10-30  

quaff 写道

ajoo 写道

偶是觉得spring的xml配置语法即使在2.0后仍然是很繁琐的。
spring的功能强大，继承了大量的第三方系统，还有acegi这类的私生子，这没得话说。理论上这是一个事实标准的胜利，是占据了先机的胜利，而不是技术上的胜利。

另外spring的灵活性也还有些疑问。

我们最近需要refactor一个遗留系统。该系统自己用property file定制了对象创建，并且在代码里面硬编码了“缺省实现类”。总而言之，是个long story。
在考虑重构这个系统的时候，没有发现spring提供温和的渐进改革方法。要用spring，似乎就不能再用现在这个property file了，也就是说，要一下子把所有用这个遗留框架的代码彻底改掉。

还有，spring也缺乏给容器外面创建的对象注射依赖的能力。


这些都是一些很细节的缺陷了。


最后说一点。凡是说用了spring就获得了ioc的好处的人，根本就没懂ioc。IoC，或者说Dependency Injection，根本不依赖于你是否用一个IoC容器。new MyBusinessObject(new SomeService())这就是一个IoC了。

1.spring的xml配置虽然繁琐了一些,但通过看xml的配置基本上就知道了整个系统的结构,对象与对象之间的关系,我基本上不用auto-wire.大家还是把spring的xml配置仅仅看作是配置,其实它也是编程,特别是spring2.0使用schema配置,还点更加明显.
2.你可以在一个ApplicationContextAware的bean里面实例化你property file里面的bean,然后注册到ApplicationContext,对外面对象的注射依赖请看
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory类里面的autowireBeanProperties(Object existingBean, int autowireMode, boolean dependencyCheck)

1。xml还是做配置最合适。一旦用作编程，往往就非常蹩脚了。我倒是还比较愿意用autowire的。如果一概manual wire，那么还要spring干啥？groovy好不好？
spring 2的schema说实话我不太理解rod为什么要引入schema这么复杂的东西。自定义tag就得要schema？ant得自定义task也不需要schema。
2。我主要是不太希望java代码依赖这个properties文件。理想情况是xml config文件里面指向这个properties文件，java代码直接读xml config文件。
3。外面对象的注射么。autowireBeanProperties还算可用吧。要是它能允许选择要注射的property名字会更实用一点。
另外，容器内没有登记的类能做contructor注射么？类似：
autowireConstructor(AClassNotRegisteredInContainer.class)


还有，对这样一个场景：
容器内很多service组件的创建需要注射appId, sessionId两个变量。
appId, sessionId这两个变量会随着程序运行的上下文不同而不同。（比如，两个线程使用两个不同的sessionId）
怎么做？莫非每个线程都要先登记appId, sessionId？还要锁定整个容器？

21 楼 domain 2006-10-30  

引用

有些人如果不被大象甚至恐龙折磨上十年八年的话，是绝对不会意识到马有多么的好驱策，多么的灵活

如果选择，他会说：马不错呀 吃的少

这个比较经典  
虽然才刚开始学spring，但是还是真正感受到了它的精彩，继续学习中

20 楼 gherb 2006-10-30  

stamen 写道

3)Spring使你更加方便地使用常用企业功能，如JavaMail，Timer，远程调用，缓存，安全等，Spring使得利用这些类库得到了很大的简化，而如果你直接用这些类库，学习曲线陡峭得很多；


Unknow---- says:
第三点是有价值了

有些人如果不被大象甚至恐龙折磨上十年八年的话，是绝对不会意识到马有多么的好驱策，多么的灵活

如果选择，他会说：马不错呀 吃的少

... ...

19 楼 nihongye 2006-10-30  

是大家只爱spring,不爱其它的，其实各有各的精彩

18 楼 quaff 2006-10-30  

ajoo 写道

偶是觉得spring的xml配置语法即使在2.0后仍然是很繁琐的。
spring的功能强大，继承了大量的第三方系统，还有acegi这类的私生子，这没得话说。理论上这是一个事实标准的胜利，是占据了先机的胜利，而不是技术上的胜利。

另外spring的灵活性也还有些疑问。

我们最近需要refactor一个遗留系统。该系统自己用property file定制了对象创建，并且在代码里面硬编码了“缺省实现类”。总而言之，是个long story。
在考虑重构这个系统的时候，没有发现spring提供温和的渐进改革方法。要用spring，似乎就不能再用现在这个property file了，也就是说，要一下子把所有用这个遗留框架的代码彻底改掉。

还有，spring也缺乏给容器外面创建的对象注射依赖的能力。


这些都是一些很细节的缺陷了。


最后说一点。凡是说用了spring就获得了ioc的好处的人，根本就没懂ioc。IoC，或者说Dependency Injection，根本不依赖于你是否用一个IoC容器。new MyBusinessObject(new SomeService())这就是一个IoC了。

1.spring的xml配置虽然繁琐了一些,但通过看xml的配置基本上就知道了整个系统的结构,对象与对象之间的关系,我基本上不用auto-wire.大家还是把spring的xml配置仅仅看作是配置,其实它也是编程,特别是spring2.0使用schema配置,还点更加明显.
2.你可以在一个ApplicationContextAware的bean里面实例化你property file里面的bean,然后注册到ApplicationContext,对外面对象的注射依赖请看
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory类里面的autowireBeanProperties(Object existingBean, int autowireMode, boolean dependencyCheck)
3.最后说一点,ajoo大牛对spring有偏见,只爱自己的yan

17 楼 ajoo 2006-10-30  

偶是觉得spring的xml配置语法即使在2.0后仍然是很繁琐的。
spring的功能强大，继承了大量的第三方系统，还有acegi这类的私生子，这没得话说。理论上这是一个事实标准的胜利，是占据了先机的胜利，而不是技术上的胜利。

另外spring的灵活性也还有些疑问。

我们最近需要refactor一个遗留系统。该系统自己用property file定制了对象创建，并且在代码里面硬编码了“缺省实现类”。总而言之，是个long story。
在考虑重构这个系统的时候，没有发现spring提供温和的渐进改革方法。要用spring，似乎就不能再用现在这个property file了，也就是说，要一下子把所有用这个遗留框架的代码彻底改掉。

还有，spring也缺乏给容器外面创建的对象注射依赖的能力。


这些都是一些很细节的缺陷了。


最后说一点。凡是说用了spring就获得了ioc的好处的人，根本就没懂ioc。IoC，或者说Dependency Injection，根本不依赖于你是否用一个IoC容器。new MyBusinessObject(new SomeService())这就是一个IoC了。

16 楼 codeutil 2006-10-29  

经历过一些事情之后，对这个也有深有体会，
除说服领导允许使用spring之外，对于别人，没有必要去自作多情的好心。
自己一天用spring干完一个星期的活就可以了，何必操心别人在拼命加班打代码呢？
好心只会被当作驴肝肺。

robbin 写道

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

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

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

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

15 楼 LucasLee 2006-10-29  

我认为在这个问题上，不会有非此即彼的结论。

1.任何框架所发挥出来的生产率严重依赖于使用者本身、项目具体特点等环境因素。所以有人觉得好有人觉得不好都很正常。觉得好的就用，觉得不好的当然应该继续用他觉得好的。

2.跟风始终不是一个好的行为，坚持自己独立的判断。我虽然倾向于unknown，但我不认为他的认识一定和我一样，但我觉得他的怀疑很有道理。

14 楼 youcai 2006-10-29  

这都是吵的很烂的问题了。
不同的项目和人有不同的场景，1个礼拜就要交工，客户根本不在意项目质量的好坏，几个action就能搞定，等等。非要spring干啥？

13 楼 YuLimin 2006-10-29  

robbin 写道

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

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

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

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

1、此人有一种强烈的想学这个技术的话，心头有结，那就有必要帮他打开这个结，对比引用一些来说即可；并告诉他：Read a bit and take it out , then come back read some more . 就行了；

2、同意啊，如果他是以一种BS的态度来谈的话，就顺他的意思啦，说他这个不行那个不行啦，反正他高兴，寒。。。自己一下。