对于EJB3的一些看法(在IBM秋季沙龙上的讨论)实际上EJB3规范我05年就略微了解了一些。9月3号，广州IBM组织了
对于EJB3的一些看法(在IBM秋季沙龙上的讨论)
实际上EJB3规范我05年就略微了解了一些。
9月3号，广州IBM组织了技术沙龙，专题介绍EJB3，JPA的技术特点。这几年由于对 Hibernate，Spring 应用经验增加，当时对EJB3 的一些疑惑和不感冒，现在更加明确了。
沙龙上主要针对Hibernate 介绍了 EJB 3的 JPA， 针对Spring 介绍了 EJB 3 的容器特性，感觉IBM有贬低 Hibernate， Spring，力推EJB 3的气势，大概是为 WAS7的推广做准备吧，呵呵。
一些明显的点就是 EJB 3为了轻量化，避免 EJB 1, EJB 2当年设计缺陷的后尘，采用了许多 Spring IOC的思想； 为了实体bean， 而又采用了 Hibernate 的许多思想，只是适当的引入了 annotation 等技术。似乎有些偷窃概念和技术，而又贬低前人的意味，这一点让人感觉很不好。
另外一点，运用 annotation 进行映射，服务发布，注入等， 着实感觉不是一个好的方案，这就是我3年前的感觉。 虽然说不一定完全用 annotation 开发，但IBM将这个未经实践检验的开发模式作为一个开发推荐规范介绍给我们客户，， 有点类似当年极力推 EJB 2的感觉。 annotation 是JDK1.5开始的一个语言级的好特性，但不能滥用。特别是在 ORM 映射，将bean发布为服务等，直接在method上写 annotation，就是一种 hard coding，通俗说就是写死的做法，如：将实体的表名写死，将属性对应的库表column写死，将发布的web service 的地址写死等， 失去了 ORM 映射配置的灵活性.
@Entity @Table(name = "STUDENT") public class Student implements Serializable { ..... } @ManyToOne @JoinColumn(name = "student_id") public Student getStudent() { return student; } 实践才是最好的选择器，就像Hibernate ，Spring 成为事实上的企业级开发标准一样。 所以我们对 IBM，Oracle 的新品宣传，新规范介绍， 还要多留个心眼，有自己的思考，不能死板的照单全收。 10 楼 xiaopang106 2008-09-24 我在用EJB3的过程中发现使用他还是很方便的，不像spring+hibernt那么麻烦，需要一大堆的配置，实体bean里面 我就用了@Entity,@Table,@Id三个注解，接口和sessionBean用@remote或者@local, @Stateless,不过没有在实际的项目中练过，纯粹是练手的。 11 楼 天一 2008-09-24 不知道楼主有没有在项目中用过。 12 楼 hity 2008-09-24 大型分布式应用EJB绝对是首选 13 楼 HenryYu 2008-09-24 JPA只是EJB3一部分，Spring和hibernate是企业开发事实标准，这估计也只是你的自己的事实标准。我们一般讨论ejb与spring，都是基于EJB容器与Spring的Bean容器层面上的比较。谁优谁劣没有绝对，比较的目的是更好地根据项目的特点进行合理的选择。 14 楼 raymond2006k 2008-09-24 SteveGY 写道我怀疑所谓的“灵活性”是否真的有存在的必要。在ORM的方法中，运行时可变的数据表名字和column真的有大量的使用吗？是否有人很容易使用Hibernate组成复杂的自定义查询方法了？我好想记得，前几天还有人推荐team规范“禁止使用HQL”的。
在实际项目中，如果数据库设计都已经发生变化，改动java源码难道不是必要的吗？或者说修改xml会比较容易？再或者说一个表增加了3个column，java源码也是不需要改变的？到底要怎样理解hard coding？把一种基于java源程序的hard coding转移到基于xml配置文件中，就算是去除了hard coding？hard coding和“灵活性”都不是绝对的。
EJB3在使用annotation，这是一种设计选择，他们既然这样选择，还是衡量过灵活性和易用性的，除去hibernate不讲，看看最近spring的某些言论，支持EJB3已经是基本一致的看法了，想想当年spring是怎么起家的，反EJB算一面旗帜，也算一点点讽刺吧。
我一直在team规范中使用iBATIS，iBATIS for java and for .net，2种语言类型的项目都用，个人认为hibernate在跨数据库支持上还可以，其他的都不怎么样。
老兄的观点谈的很仔细啊，多谢了， 论坛就是需要这样热烈的讨论。呵呵。
XML配置的灵活性我想不用怀疑，经过大量开发实践，特别是大型项目的朋友我想都是对此深有体会的。
只是现在EJB3将annotation等作为最佳实践推荐给客户，到是值得怀疑的，虽然 EJB3还未规范用起来，但帖子是个人根据几年开发经验谈谈此类问题的感受。
推荐使用 Hibernate 时不用 HQL，用命名SQL的也是我啦，呵呵，此点似乎与官方规范，推荐用法都有悖，所有很多网友反对我。呵呵。
遇到新产品，新规范，一般人都是照单全收。我想有一些怀疑，探索精神还是需要滴，呵呵。
感谢你的热情讨论，希望以后多交流。 15 楼 davexin 2008-09-24 ejb3有他的用途的，如果你们的应用不用使用ejb3也能方便解决得问题的话，你就没有必要使用ejb3，ibm当然是推自己的东西了。不过如果你有分布式和集群应用的话，ejb3就是很好的解决方案。我们现在就使用ejb3做的，感觉还是可以的，开发也挺方便。 16 楼 slaser 2008-09-24 保持代码纯洁性比较好，annotation没有必要。写xml不比写annotation花时间多，而且xml比annotation更容易理解，也更灵活。如果一定要降低开发难度，我觉得还是引入jruby一类动态语言，java不应该变的复杂。 17 楼 slaser 2008-09-24 SteveGY 写道我怀疑所谓的“灵活性”是否真的有存在的必要。在ORM的方法中，运行时可变的数据表名字和column真的有大量的使用吗？是否有人很容易使用Hibernate组成复杂的自定义查询方法了？我好想记得，前几天还有人推荐team规范“禁止使用HQL”的。
在实际项目中，如果数据库设计都已经发生变化，改动java源码难道不是必要的吗？或者说修改xml会比较容易？再或者说一个表增加了3个column，java源码也是不需要改变的？到底要怎样理解hard coding？把一种基于java源程序的hard coding转移到基于xml配置文件中，就算是去除了hard coding？hard coding和“灵活性”都不是绝对的。
EJB3在使用annotation，这是一种设计选择，他们既然这样选择，还是衡量过灵活性和易用性的，除去hibernate不讲，看看最近spring的某些言论，支持EJB3已经是基本一致的看法了，想想当年spring是怎么起家的，反EJB算一面旗帜，也算一点点讽刺吧。
我一直在team规范中使用iBATIS，iBATIS for java and for .net，2种语言类型的项目都用，个人认为hibernate在跨数据库支持上还可以，其他的都不怎么样。
我一直觉得表结构不一定适合用对象表示，我认为xml描述的表结构比java实体类更为优美，所以我觉得，hibernate可不可以不要写java实体类了，直接一个hbm文件全部搞定，反正那个实体类不过承载数据而已，可以用动态对象代替。
18 楼 likeblood 2008-09-24 ejb3的规范就是king领导的
ioc也不是spring的思想
都是大同 19 楼 grandboy 2008-09-24 slaser 写道保持代码纯洁性比较好，annotation没有必要。写xml不比写annotation花时间多，而且xml比annotation更容易理解，也更灵活。如果一定要降低开发难度，我觉得还是引入jruby一类动态语言，java不应该变的复杂。
这点可能公说公有理，婆说婆有理了。xml比annotation更容易理解，可能有相当多的人都不认同。annotation至少在compile时还能检查一下是不是拼错了，或者语法错误。当然就是修改就要重新编译了。xml里的有些错误真是太难找了。
要选择适合自己项目的技术就行了。 20 楼 raymond2006k 2008-09-24 slaser 写道SteveGY 写道我怀疑所谓的“灵活性”是否真的有存在的必要。在ORM的方法中，运行时可变的数据表名字和column真的有大量的使用吗？是否有人很容易使用Hibernate组成复杂的自定义查询方法了？我好想记得，前几天还有人推荐team规范“禁止使用HQL”的。
在实际项目中，如果数据库设计都已经发生变化，改动java源码难道不是必要的吗？或者说修改xml会比较容易？再或者说一个表增加了3个column，java源码也是不需要改变的？到底要怎样理解hard coding？把一种基于java源程序的hard coding转移到基于xml配置文件中，就算是去除了hard coding？hard coding和“灵活性”都不是绝对的。
EJB3在使用annotation，这是一种设计选择，他们既然这样选择，还是衡量过灵活性和易用性的，除去hibernate不讲，看看最近spring的某些言论，支持EJB3已经是基本一致的看法了，想想当年spring是怎么起家的，反EJB算一面旗帜，也算一点点讽刺吧。
我一直在team规范中使用iBATIS，iBATIS for java and for .net，2种语言类型的项目都用，个人认为hibernate在跨数据库支持上还可以，其他的都不怎么样。
我一直觉得表结构不一定适合用对象表示，我认为xml描述的表结构比java实体类更为优美，所以我觉得，hibernate可不可以不要写java实体类了，直接一个hbm文件全部搞定，反正那个实体类不过承载数据而已，可以用动态对象代替。
Ofbiz 就是这样的框架，一个 GenericValue 代替所有的 VO，还比较好用。 21 楼 mreay 2008-09-24 raymond2006k 写道
annotation 是JDK1.5开始的一个语言级的好特性，但不能滥用。特别是在 ORM 映射，将bean发布为服务等，直接在method上写 annotation，就是一种 hard coding，通俗说就是写死的做法，如：将实体的表名写死，将属性对应的库表column写死，将发布的web service 的地址写死等， 失去了 ORM 映射配置的灵活性.
你大可以使用xml文件来覆盖annotation,EJB3是xml优先。所以一般annotation中代表的只是默认的配置，适用于一般情况下。如果有需要使用xml来写些特别的地方。个人认为灵活性更高。
22 楼 herenhuang 2008-09-24 其实在code中注释还是比在xml中好的，xml有些泛滥了。 23 楼 wang19841229 2008-09-25 个人感觉现在SSH中配置文件大量使用XML，有的时候是项目中的XML文件太多了，难以管理所有个人感觉注释也是一个不错的发展方向。 24 楼 hantsy 2008-09-25 项目大了，还是觉得annotations的方式比较方便，维护大量xml配置也是件头痛的事。
jpa,ejb3 都可以使用xml配置，但是已经没有必要了，annotation是直接写在代码上的，配置量会大大减少。 25 楼 tibetjungle 2008-09-25 ejb3比ejb2的确是一个巨大的进步，很喜欢ejb3的pojo编程风格，个人认为注释的运用可以提高生产效率。
另外，如果不做分布式、集群，还是用spring的好。jpa实现的不过是hibernate的一个子集。 26 楼 firemoth 2008-09-25
算了吧，hibernate的配置以前不是也有xdoclet，现在的hibernate也全面支持annotation，连spring也全面支持annotation，这是个趋势，不光ejb3什么事
前面一位兄弟说的很对，分久必合合久必分，牛人们每年总要搞些噱头才能骗钱，熟悉业务，做好商业逻辑的封装重用，做好领域对象的设计，熟悉领域驱动开发才是重点，管它们用那种orm，过分重视框架感觉本末倒置
27 楼 liqiuxi 2008-09-25 据我所知，ejb的jpa的设计者和hibernate是同一个人，sun挖过去的 28 楼 zhou7707 2008-09-25 标题党
不懂不要乱说,无知并不有趣 29 楼 thinkapig 2008-09-25 我长期从事电信级系统的研发维护，知道配置文件的大量存在是维护工作的一个大障碍；annotation确实是JPA的一个比较好的选择；hibernate在2个项目中实践过，无论是测试、开发都 比较麻烦；后来我写了一个pojo方式的数据库访问框架，总算摆脱这个烦恼；每个技术人员接触的领域都不一样，所以看问题的角度也不一样；EJB在电信领域的地位还是很高的；SSH不能很好解决事务分段提交的问题；
