POJO编程模型
原来的EJB编程模型存在的问题
笨重，业务程序与EJB框架耦合严重，无法在JEE平台之外运行组件，开发-打包-部署-测试流程长且复杂。
POJO编程模型的优点
简单，轻量，无耦合
轻量级容器和控制反转
轻量级容器
有这么一个容器，能够提供业务需要的各种组件（比如数据库连接、事务、缓存），而这些组件是同个“插拔”的方式引入到容器来的，业务按需通过组合的方式引入相关的组件
控制反转
原来业务程序依赖某一组件或者某一其他业务，需要自己显示地展示依赖逻辑，比如 类A,依赖类B和Jdbc, 方式大概如下：
public class B {}
public Class A {
private B b;
private JdbcTemplate template; // jdbc
}
public A() {
this.b = new B();
this.template = new MysqlJdbcTemplate();
} 这时 A对B和jdbc的依赖初始化需要A来控制，A与B/Jdbc就耦合起来了，如果更换B/jdbc的实现，需要改动代码。控制反转就是把这些依赖，初始化等，交给容器，初始化好后，塞给A,A不参与，这样，耦合性大大降低；控制，由A转换到了容器，故称控制反转。
控制反转主要由两种形式：依赖查找和依赖注入
依赖查找：容器向其管理组件提供了回调方法，而组件则通过这些回调方法与容器进行交互并显式地获取他们的依赖项，这种情况下，通常使用一个查找上下文来访问依赖组件以及容器管理的其他内容资源。如应用实现ApplicationContextAware,把BeanFactory回传给应用，供应用获取相要的资源,再比如JDNI通过上下文查找到DataSource.
依赖注入：组件提供合适的setter或者构造函数，以便容器可以注入依赖组件。
依赖注入
基本原则是，应用程序，不应该创建、查找他说依赖资源或者协作者，交给容器，由容器负责这些依赖资源的创建和注入，实现资源查找的外部化。主要分为 通过构造函数注入和通过Setter方法注入。
通过构造函数注入：能够在初始化时就固定好初始化的值，简洁，但无法处理循环依赖问题，重载构造器也会产生问题
通过Setter方法注入：在组件完成创建后，可以进行重新配置，组件的依赖，可以在运行时进行更改，可以解决循环依赖问题