我最开始是c程序员，后来转来做java，算来做java差不多也有10年了，即使不能说非常精通java，最起码也能算是很熟悉java的了。对于现在很流行的spring，IOC、AOP这些了，我真的很纳闷，不理解这东西为什么好，希望有人能够给我解惑。
个人感觉spring确实解决了一些问题，让程序员只面向接口编程，这确实带来了一些好处，可我总觉得这带来的问题也不小啊。本来几个类几个方法可以非常清晰的解决的问题。非要要求搞一堆接口，强制分很多层，特别对于一些新手来说，层分的又不是很合理，命名又不规范。写出来的代码也是非常的乱。
因为我现在一般也都不写代码，但是需要经常看其他人写的代码，有时候看用了spring的，特别是一些写的质量不是很高的代码，命名也不太规范的情况，想搞清各类之间的关系真不容易，一个非常简单的业务，却在无数接口与实现类中转来转去都转晕了。
------解决方案--------------------
提到Spring就不能不说控制反转Ioc//Inversion of Control
和依赖注射DI//Dependency Injection
什么叫控制反转呢？
套用好莱坞的一句名言就是：你呆着别动，到时我会找你。
什么意思呢？就好比一个皇帝和太监
有一天皇帝想幸某个美女，于是跟太监说，今夜我要宠幸美女
皇帝往往不会告诉太监，今晚几点会回宫，会回哪张龙床，他只会告诉太监他要哪位美女
其它一切都交由太监去安排，到了晚上皇帝回宫时，自然会有美女出现在皇帝的龙床上
这就是控制反转，而把美女送到皇帝的寝宫里面去就是注射
太监就是是框架里面的注射控制器类BeanFactory，负责找到美女并送到龙床上去
整个后宫可以看成是Spring框架，美女就是Spring控制下的JavaBean
而传统的模式就是一个饥渴男去找小姐出台
找领班，帮助给介绍一个云云，于是领班就开始给他张罗
介绍一个合适的给他，完事后，再把小姐还给领班，下次再来
这个过程中，领班就是查询上下文Context，领班的一个职能就是给客户找到他们所要的小姐
这就是lookup()方法，领班手中的小姐名录就是JNDI//Java Naming and Directory Interface
小姐就是EJB，饥渴男是客户端，青楼是EJB容器
看到区别了么？饥渴男去找小姐出台很麻烦，不仅得找，用完后还得把小姐给还回去
而皇帝爽翻了，什么都不用管，交给太监去处理，控制权转移到太监手中去了
而不是皇帝，必要时候由太监给注射进去就可以了
看到Spring的美妙了吧，Spring还提供了与多个主流框架的支持
可以和其它开源框架集成
------解决方案--------------------
都2个星的人了....
业务简单，项目规模小，有时候用spring的确挺麻烦，毕竟需要各种配置。稍微大点的项目，用spring还是挺好的，一些类实例化等都不要自己考虑，后期维护和改造也更方便（比如一个类是其他类的成员变量，以后这个类变动了，其他引用类直接在spring中配置，根本不用关心有哪些类引用它了）。
------解决方案--------------------
大牛，我这么理解的。
像spring框架，有自己一定的优势，面向切面和控制反转。
但现在很多比较小的工程都一味的追求ssh架构，将spring滥用了。
本来就比较简单的登陆验证也要搞个spring进去，完全大材小用，反而给项目中定义了层层接口，层层实现。
相对于比较大的工程，多模块开发，这时定义接口，各自开发才是面向接口的优势，也就是spring的优势。
------解决方案--------------------
控制反转 IOC 重要的特点是 直到程序运行的时候才去决定 程序的下一步流程。
比如说一下程序方法
如果参数没有实现接口, Parametre 没有实现接口, 那么势必运行的流程就已经定死了肯定执行Parametre 实例的doSomething发明合法
public void execute(Parametre par) {
par.doSomething();
}
但是如果Parametre 是一个接口，那情况就不一样了, par.doSomething(); 接下去的流程就不固定了是动态的，我想要它执行什么流程，只要实现这个接口，将参数传入就可以了。这样的灵活性更高。
所以spring 基本上所有的class 都是实现接口的。而主要的就是要这个效果。
不过这要求程序原的素质更高。理解能力更强。多一根筋去想 接下去的流程是什么样的，因为任何方法接下去的流程可能都是不固定的。
------解决方案--------------------
我感觉这些框架重要的不是解决了什么问题，而是这些框架的思想是合理的。
------解决方案--------------------
看spring 的作者的书 《j2ee without EJB》
里面有他的设计思想的详细说明，面对的问题，动机，解决问题的办法。
其他人说 都是看饼子 猜饼子是怎么做的，还不如直接问原作者的设计想法。
------解决方案--------------------
AOP的功能自不用说。这个例子很有意思，皇上是不需要告诉太监他需要哪个美女的， 只要告诉太监他需要一个女人(能那个)，要美(这是一个标准，就像接口一样，美也有不同美法)就OK了。
对于皇上而言他不需关注美女的细节， 他越关注，太监就越不好办。 就像代码中，面向接口编程的意义就在于此：依赖抽象而不是具体的实现。 这样做的好处是：可以提供不同的实现为调用者服务以满足复杂情况， 而调用者无需修改代码， 这就是解耦。
而IOC正是让这个解耦变得可能。
------解决方案--------------------
写个spring命名规范，让大家依规办理，你的问题之一在于没给手下人立规矩。
------解决方案--------------------
小项目是否每一偶必要啊。
------解决方案--------------------
看下书籍《 spring in Action》
------解决方案--------------------
才接触spring不久,对于新人的感觉而言,就是觉的spring注入的对象,可以是真实对象,也可以是代理对象,
注入的真实对象,用起来的效果和普通的new()出来的对象一样,
但是注入的这个代理对象,把许多服务对象的方法整合在一起用,就相当于增强了,特别是给业务逻辑层加事物和日志,自己在写代码时,只需要专注于逻辑的实现,到时交给spring来管理,写好配置,让spring给我们的方法加上事务或者日志.
------解决方案--------------------
这种时候，只可能用铁血手段，强行让你记住命名规范，记不住就“打”到你记住为止。
我经历过的最铁血的手段是，规定缩进2格，你不缩进或者多了少了几个空格，就按照最严重的BUG算（比如编译不通过，或者大于号写成小于号来算），一个地方100块（考虑十年前的工资水平）。看你记得住吗？
另外，如果很大的项目，我反而建议包和/或类的命名序号话。比如A001Xxxx什么的。A是大的模块的编号，001是小的模块的编号之类的。然后具体A001干什么的，写到文档里面去。