EJB 和 Spring :
这两个框架有共同核心设计理念：将中间件服务传递给耦合松散的POJOS -- 对“耦合松散的POJO”的设计。 这样的框架利用截取执行上下文或在运行时将服务对象注入POJO来把应用服务“缠绕”到POJO。POJO本身并不关心这种“缠绕”，对这种框架结构也没有什么依赖。因此，开发者可专注于业务逻辑和脱离框架的POJO单元测试 . 除此之外， 由于POJO并不须要继承框架的类或实现其接口，开发者能够极其灵活地搭建继承结构和建造应用。
然而，在拥有同一理念的同时，两个框架结构使用不同的方式来传递POJO服务。
为什么用Spring ?
spring的使用是我们对ejb的另一个选择，由于ejb太全，我们一般项目不需要使用到ejb中的许多特性，所以我们选择了一些轻量框架，spring的一个很大的好处就是当我们需要该项功能的时候，我才配置该项功能，不需要的时候就不必理会。但是个人感觉，当项目庞大到的确需要分布式部署的时候，还是使用ejb更有优势。还有就是spring对其他的一些优秀框架的整合，也使得spring脱颖而出
spring用户多，文档比较全，各种插件支持好，如果单纯比BI，他不见得是最优秀的。代码也乱七八糟的。但是对于团队新人来讲，学习成本低、稳定性足够而已。
1，ejb这个容器包含太多组件了。而且这些组件，都是必须的，并且十分复杂，难以理解。尤其是ejb2.0中太多。在大部分项目开发中只需要几个简单的组件就可以了，但EJB无法根据自己的需求进行组建。
这样无法达到一种默认的标准。就是轻 -- 好维护，升级，开发也简单。
spring的基本容器只有ioc，默认的aop实现是基于ioc实现的，然后spring，直对其他框架，库，标准进行兼容。这样有很强大的灵活性，扩展性，维护性
2，成本，庞大的ejb,学习成本，开发成本过大。spring简单的多。
3，spring体系更加完善，包括data模块，test模块，等等
4，ebj属于付费的产品，项目成本提高。
J2EE 的 13 种规范 :
目前接触到的有 :
- JDBC -- Java数据库连接
- RMI -- 远程过程调用
- JSP
- Servlet
- XML
- JMS -- Java消息服务
- JavaMail -- 存取邮件服务器的API
不理解的 :
- JAF -- 一种框架 , 安全认证服务
- JTA -- 事务处理的API
- JTS -- 用面向对象的机制来处理事务
- JNDI
- EJB
- Java IDL/CORBA -- 可以理解为一座桥 , 用来连接不同的系统
开发演变过程 :
原始开发 : 使用 servlet 接收请求 , jsp 输出响应页面 , DButils,JDBCUtils 操作数据库
域对象 , JSTL标签 , EL 表达式语言
servlet -- request , response , session
客户端浏览器 -- cookie
过滤器 , 监听器
servlet , request , coookie , session 生命周期
重定向 , 请求转发区别
中文字符乱码解决
json
J2EE 三层模型 : web层(JSP+Servlet) , 业务层(EJB) , 持久层
框架开发 : SSH
struts2 :
拦截器 , Action , ognl&valueStack
配置文件
ActionSupport
hibernate :
ORM 对象关联映射 , 对JDBC的封装
两个配置文件
持久化类 PO
数据对象的三种关系 ,级联 , 一级缓存
多表操作 , 内连接 , 外连接 , 迫切..
优化
Spring :
业务层 , IOC/DI , AOP , 框架整合 , 事务管理 , spring容器管理bean , 反射 , 动态代理
Spring Data Access : JDBCTemplate
SSH 整合
配置文件
Maven : 项目管理工具 , 聚合/继承
json : 数据格式 , jackson , fastjson 框架
Ajax 开发
注解开发
MVC 三层模型 : SSH , SSM 框架
