delvin

EJB俨然成为了一个任人打扮的小姑娘。现在你只要和一个国内Java开发人员交流，基本都能听到他们说EJB的缺点，即使他没有使用过。
为此我花了点时间，试图分析下EJB的优点和缺点，以及EJB对Java技术社区的贡献。

我使用了EJB有6年时间，从接触Java就开始学习EJB,使用过EJB1，EJB2和EJB3。

我总结的EJB(EJB1和EJB2)存在的问题有：

目标定位不清
编成模型复杂
开发和移植困难
部署描述符陷阱
类加载陷阱
测试困难
破坏面向对象设计
部署慢
运行时需要EJB容器，代价高
维护困难
学习曲线大

下面我们逐一分析
一 目标定位不清
假如你看过EJB早期规范，你会发现，规范中队EJB的目标定位有11项之多。为了分析方便，我引用了EJB2.1版本中有关EJB目标定义的内容（注：序号是我加上的）。
The Enterprise JavaBeans (EJB) architecture has the following goals:
 1）The Enterprise JavaBeans architecture will be the standard component architecture for build-
ing distributed object-oriented business applications in the Java programming language.
 2）The Enterprise JavaBeans architecture will support the development, deployment, and use of
web services.
3）The Enterprise JavaBeans architecture will make it easy to write applications: Application
developers will not have to understand low-level transaction and state management details,
multi-threading, connection pooling, or other complex low-level APIs.
4） Enterprise JavaBeans applications will follow the Write Once, Run Anywhere? philosophy of
the Java programming language. An enterprise bean can be developed once, and then
deployed on multiple platforms without recompilation or source code modi?cation.
5） The Enterprise JavaBeans architecture will address the development, deployment, and runtime
aspects of an enterprise application’s life cycle.
6） The Enterprise JavaBeans architecture will define the contracts that enable tools from multiple
vendors to develop and deploy components that can interoperate at runtime.
7）The Enterprise JavaBeans architecture will make it possible to build applications by combin-
ing components developed using tools from different vendors.
8） The Enterprise JavaBeans architecture will provide interoperability between enterprise beans
and Java 2 Platform, Enterprise Edition (J2EE) components as well as non-Java programming
language applications.
9） The Enterprise JavaBeans architecture will be compatible with existing server platforms. Ven-
dors will be able to extend their existing products to support Enterprise JavaBeans.
10） The Enterprise JavaBeans architecture will be compatible with other Java programming lan-
guage APIs.
11）The Enterprise JavaBeans architecture will be compatible with the CORBA protocols

从这些目标中我们可以发现，几乎没有目标是针对开发人员效率的。从这次目标中我们就可以隐约的感到EJB不是对开发者友好的技术。
从这些目标中，我们可以发现EJB的雄心过于庞大，而EJB出现的时代，还不足以在一个规范中解决这些问题。从EJB后来被人诟病最多的实体Bean，只是EJB的一小部分，但恰恰就这点就要了EJB的命。

EJB目标中把本不应该放在一起的东西给放在了一起，比如分布式和实体映射。而且错误的假定了使用分布式的场合。按照Spring创始人的说法
，分布式只有20%的应用要用，而80%是不需要的。
我们现在知道EJB目标不清楚，那我们免不了要问，当初Sun为什么要这样定位EJB？
也许除了EJB早期规范组的人，没有人真正清楚为什么，我们此处只能留到以后事后诸葛亮下（注：此处我以后会用一片文章来分析产生的原因）。

二 编成模型复杂

EJB组成复杂：
 一个EJB有好几个东西组成，具体有主接口 ，远程/本地接口，Bean类，部署描述符
虽然开发社区发展了Xdoclet技术，但也只是解决了一部分问题。用Xdoclet，编译时需要产生代码，当EJB多时，这是很耗时的。

有过开发经验的人都知道要是修改一个小东西需要修改几个文件的话，那工作效率是上不去的，另外在考虑到EJB的需要部署，启动服务器的时间，修改EJB简直是痛苦啊。这样必然导致开发周期长。
  编写（定义接口，  实现Bean， 编写部署描述符）-》打包部署-》     启动服务器-》测试。

早期开发中，我们还遵守规范中按角色编程的要求，导致角色多，沟通成本高，比如Bean开发者开发Bean，部署员打包部署，系统管理者管理服务器。

三 移植困难（特别是Entity Bean）
规范中说的编写一次，到处部署的承诺，基本是一句空话。结果变成了编写一次，到处重写。特别是实体Bean，基本上迁移一个服务器，就相当于用HIbernate重新的工作量，还不考虑测试的困难性。规范中对实体映射定义的太过于宽泛，导致每个厂商都需要自己的ORM实现，引入 特定厂商的部署描述符，又因为J2EE中除web外，类加载的定义没有明确，导致产生特定厂商的类加载机制和打包方式，还有就是特定厂商的服务查找方式。

四 部署描述符陷阱
 1）EJB采用了当时流行的使用Xml作为粘合剂，并且实现厂商都引入了自己的配置文件。结果导致编写过多的配置文件。以JBoss为例要写要写三个配置文件。XML配置文件复杂，手工编写比较困难，早期IDE中可视化编写XML效率有不高，导致开发人员开发效率大大降低。更痛苦的是修改后，不能及时生效。大家想象一下，如果你有多个EJB，修改一个需要重新部署和启动服务器，那是怎样的浪费时间。以我曾经的一个项目为例，约有100个EJB，部署和重启JBoss需要几分钟，重要不是浪费时间，而是那种挫折感。
 2）标准的ejb-jar.xml部署描述符把一些重要的信息（比如指定EJB的JNDI名字和配置实例池）都留给容器提供商，
我们一般都需要一个额外，特定于容器的的部署描述符，比如weblogic-ejb-jar.xml。这样导致编写和移植的困难。

五 类加载陷阱（类加载器复杂，并且不清晰）

J2EE规范（Java EE）对EAR中web和ejb的加载没有明确定义。比如一个EAR有多个EJB，每个EJB都依赖一些其他类库，那么对这些被依赖的类库到底是怎么被加载的，类的可见性怎么样，规范没有规定。这样每个厂商都有自己的一套东西，导致不同服务上，要用不同的打包方式。

六   测试困难
J2EE测试难是有目共睹的，其中EJB测试困难时出了名的。测试困难的原因时，EJB运行需要容器插入什么服务，而启动服务器是很高昂的代价。
后来虽然开发社区采用Mock等技术试图解决这个问题，但从开发实践来说，还是有难度的。

注: 以下几点问题，还需要详细分析，由于时间问题，暂时只是列出来。
七   破坏面向对象设计
八  开发周期长，部署慢
九  运行时需要EJB容器，代价高
十  维护困难

但说实话EJB也是有贡献，当然它的贡献更多是理念层次，在实现层面很失败。另外，也正是他的失误，在批判EJB的基础上发展起Spring，给开发人员带来一股新风。