Spring--也许正成为一个EJB

LZ这段话我超级赞同的, 很多项目都是为了面向接口编程而面向接口编程, 庸人自扰之.
比如很多项目喜欢弄一个service接口, 然后对应一个serviceImpl实现类, 在action里持有这个service接口, 然后通过spring注入唯一的一个实现类serviceImpl, 这就是他们所谓的面向接口编程了.
在这种场景下完全不需要抽象出一个接口, 直接一个service具体类就ok了

Spring使你更加方便地使用常用企业级功能，如JavaMail，Timer，JMS，缓存，安全等，Spring使得利用这些类库得到了很大的简化，而如果你直接用这些类库，学习曲线陡峭得很多；
即使为了接口而接口，但是也是规范了大家的code，更容易team work

理解楼主的担心，但是觉得没什么意义

完美的程序是没有的，而且咱们的大环境就是如此，程序写的再牛逼没用啊，会忽悠才是王道

正解。。。

实质上没有任何区别，java的组件相比较c++来说，已经简单太多了。
所谓方便使用，不过是你适应了Spring的调用方式而已，按照官方manual写调用，也很简单。
但是你要想使用这些组件类库更深入的功能，早晚都要抛开spring。

楼主这是无的放矢，内容很让人失望。
如果是你列出的那两点，我觉得你应该更多考虑团队的结构问题，因为显然在你的团队里缺了一个架构师。

开始的时候我也这样认为,后来在一个项目中果断去掉接口, 直接一个service具体类,
但是再后来才发现自己错了,接口的编程模式不是凭空而来的,是最佳实践...
特别是在项目大一点的时候,

另外我使用spring也是因为要取他的事务管理,
后来尝试struct2, springmvc, 最后选择springmvc.
spring基本上是使用注释, 只有一个主配置文件,主要是配置数据源,事务管理.

基本就是使用springmvc + spring + mybatis组合,

一个重量级，一个轻量级怎么比较。你想让spring管理的bean放到xml中，想自己代码管理的用自己的工厂方法，多么灵活，我不认同你观点

顶楼主，我曾经因为类似言论被喷了很多次，今天终于看到一个持相似观点的人，顶起。