EJB3与EJB2架构对比2

　　无论J2EE还是Java EE中，JNDI是一个好像不起眼，但是极其重要的概念，不理解JNDI可以说，对J2EE或JavaEE只了解一半。

　　JNDI本来是EJB2中比较复杂的一个概念，不同容器有自己的JNDI名称，由此EJB2引入了第三者EJB-Reference，虽然解决了代码中耦合JNDI名称问题，但是又带来了更加烦琐的配置，这种现象当然被JavaEE5.0继续继承了下来，问题远非这么简单。

　　J在Java EE5.0中(包括EJB3和Web环境)，当我们需要访问一个JNDI环境下资源时，有两种方式：除了传统EJB2中的JNDI调用方式;还有一种就是：使用依赖注射Ioc模式，这个依赖注射的表达方式是使用annotations。

　　因此，在EJB3中，必须好好搞清楚annotations、依赖注射和JNDI之间的关系，如果这个问题不弄明白，EJB3就绝非EJB2那么容易搞定，当然，搞定了的结果很简单，让人感觉简化轻量了，真不知道EJB3这种简化是不是有点象”掩耳盗铃“。

　　可以总结一句：凡是EJB2中使用配置文件定义的;EJB3一般都可以使用 annotations定义(当然EJB3也支持配置文件定义);凡是EJB2通过JNDI寻找的资源(调用容器中其他EJB、调用环境变量等Resource资源等)，都是可以依靠annotations+依赖注射机制完成。

　　JPA替代实体Bean

　　.如果说EJB3与EJB2变化最大的部分，就是持久层使用Java Persistence API 替代了EJB2的实体Bean，这样，我们通过Evans DDD建模得到的Domain Model类可以直接持久化保存到数据库，不像EJB2中还需要在Model类和实体Bean中进行一次转换。

　　EJB3引入EntityManager进行需要持久实体的查询及其新增修改;EntityManager非常类似JDBCTemp/HibernateTemplate等持久化模板。

　　JPA和JDO以及Hibernate等O/R mapping框架都是非常相似的。

　　虽然在JPA中，我们都可以使用Annotation来替代配置，实现很多过去需要专门配置文件才能实现功能，不再一定需要 每个服务器不同的cmp映射文件，增强了移植性，但是EJB3还是需要 一个叫persistence.xml配置文件，在这个配置中进行数据库JNDI配置;当然，还有一些和具体服务器有关的配置属性，如果使用JBoss，JBoss的JPA底层使用Hibernate实现，因此在persistence.xml要进行有关Hibernate属性配置：

　　EJB3.0引入了类似AOP中的拦截器概念(注意，AOP不只等于拦截器，所以不能认为EJB3就是完全AOP了)，JBoss使用JBossAOP来实现拦截器功能，自己定义的拦截器方法可以拦截任何一个业务方法或生命周期事件回调;拦截方法可以在bean中定义或专门的拦截器类。

　　NullChecker和ArgumentsChecker是StatelessSessionBean两个拦截器，在拦截器NullChecker中，必须指定的拦截方法为@AroundInvoke。

　　总结

　　总之，从上面EJB2和EJB3的总结上看，EJB3.0在EJB2基础上，引入了更多概念，最大变化就是Annotation替代了配置文件，对于一些配置文件厌恶者来说，是一个好事;但是在实战中，在一些依赖注射不能照顾到地方，我们还必须和更加复杂的JNDI名称打交道，这恐怕是EJB3的一个不是很完美的地方。

　　关于EJB3中可测试性的优点被很多人津津乐道，将EJB脱离容器测试，虽然可以进行微观的单元测试，但是脱离容器就是脱离特定完整的业务场景，所以，基于容器的(也就是基于完整的业务场景)单点跟踪调试才是最重要的，这些必须依赖开发工具的发展，目前已经在Eclipse3.2以后版本+WPT(或JBossIDE/Lomboz)中实现，这个功能适合大部分J2EE/JavaEE程序。

　　所以，个人对脱离容器的测试要求并不以为然，而这个曾经是Martin Fowler定义POJO的主要内容，因为在过去容器概念刚刚出现时，很多人都有容器恐惧症，以为容器都是不透明的，我们的业务对象放入进去，就失去了控制，这些都是落后设计观念导致，其实，Java语言本身提供的可跟踪性和介入性是非常强大，目前性能跟踪工具Profiler可以在容器运行时，跟踪到容器中某个具体类占据CPU多少，占用多少内存资源，那么一个单点调试岂是一个个所谓容器可以阻挡的?容器是Java语言的特点，ClassLoader决定了Java就是一个容器性的语言，关键这个容器是必须透明的。