Author fancyhf@163.com fancyhf.mblogger.cn
一直到实做一个ejb3，才发现此EJB3已非彼EJB1.x/2.x，尤其是实体Bean方面，简直面目全非。
感觉sun对大众繁琐、效率的抱怨，做出极大的让步，放弃了旧EJB中面向对象的理想主义。
现在的EJB3，基本只余下Session Bean，让Session Bean来负责任何db操作；所谓的Entity Bean，退化成纯粹的Data Value对象，并不负责自身的固化工作。
没有了独立的实体对象，EJB3跟.Net没有实质上的区别了。
这个框架，就是采用Hibernate概念来颠覆实体Bean概念。
EJB2.x及EJB1.x年代，我们必须定义一个PeopleEntityBean，让其ejbCreate(...),ejbStore(...),ejbRemove(...)来执行对数据库的insert,update,delete操作。然后，再定义一个PeopleFacade的SessionBean，在SessionBean的updatePeopleName(...)方法中，直接找到people对象，通过people.setName(...)来改变值。
这个年代，虽然编程、配置繁琐，但至少是一种纯OO的概念，每个对象分工独立完成自己的事。借助EJB Patterns、FrameWork和自行开发的工具，效率也不是不可以提高。
但到了EJB3，尽管也把People对象标注成@Entity，但对其的create、store、remove，却一定要在SessionBean中的 updatePeopleName(...)方法中，额外调用EntityManager的 persist()方法来把数据保存进数据库。
这样看来，@Entity一把又有何意义呢？
可见，Sun的EJB最后是屈服于Hibernate，把颇具特色颇具Java世界国情的Entity Bean给牺牲掉。现在的EJB3，就是Session Bean + Hibernate(or JDO)，当然开发绝对比较简洁了。
其实，EJB3也可以考虑让@Entity对象自行固化（create,update,remove），比如标注为@Entity的类一定实现某一个定义了create,update,remove的简单接口，然后由ejbc工具为这个类产生产派生类，再由派生类通过EntityManager来固化，而不是把固化拖延到Session Bean中。
也许EJB3概念更容易实现大型分布式系统上的集群等；可是对于中小型系统，完全只用Hibernate或者JDO，是不是更方便？
就是使用EJB3，也大可只用Session Bean，直接写sql通过JDBC操作就好了。
我预计，将来的Java世界，哪怕是企业级应用，皇家血统的EJB也不一定被采用，更多的如Hibernate这种开放式的概念，才会真正推动Java世界进步。
Java唯一胜过微软的，也就是其开放性，一个东东，连标准都开放了，能被民间IT精英们无穷无尽的扩展，并实时可能被册封为官方承认的正式标准(如Hibernate)，那么这个东东的吸引力和威力也会越来越大。更多的企业，会乐于让自己的架构师在sun的企业极标准上，兼顾其他流行的企业极framework，构件具有行业特色的open的架构，使其成为企业产品卖点之一。而微软的.Net之类，这方面的开放性应该是不如Java的。
好在EJB2.z一直都有效，所以我们这边漂亮的framwork可以一直用下去。如果别的企业也多几个这样开发简化、采用BMP、效率高、支撑了大型的业务系统的framework，那么民间的抱怨会少一些，sun也不会轻易在EJB3中放弃Entity。
