和一个朋友的聊天，他比较排斥Spring

又不是在学校上课，有时候懒得理这帮人，直接对他们大吼一声：Just do it

我们用spring就像是使用一本教科书一样，  用得最多的是。Spring的事务管理。也就是用Spring管理我们的业务对象。然后暴露ApplicationContext跟你的web层。。  其他的一些可能也有用到，  web service， 计划任务， ejb jms支持等等 。。  但我做过的项目大多数都是使用spring的事务管理部分。。

哈哈，同意robbin的观点。
好不好用得需要别人的主观体验！

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

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

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

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

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

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

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

偶是觉得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

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