一些疑惑

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 框架