用企业级JavaBeans前需要考虑几个因素

企业级javabeans(ejb)是j2ee平台中最复杂的技术之一，因此一些开发人员不愿意在他们的项目中部署ejb。

本文面向那些仍旧对是否投入时间和精力学习并在他们的项目中部署ejb技术持观望态度的开发人员。首先，我们介绍了ejb的优点和缺点，然后，说明了何时你可能需要或不需要使用ejb。

最后通过说明我对ejb错误观念一些看法得出结论。

优点

规范：ejb是一项技术规范的技术。（这既是ejb的主要优点也是一个主要缺点。）ejb规范几乎描述了实现的所有方面，包括数据类型，组件生命周期，角色分配以及很多其它方面。

与j2ee紧密结合：j2ee平台中有一组完整的服务器技术，包括ejb和其它非常有价值的技术诸如servlets，javaserver页，java消息服务，j2ee连接器体系结构，java数据库连接，java认证与授权服务，java事务api和javamail等。这使得j2ee和ejb成为一个很有吸引力的解决方案。

可升级性：只要你将大部分资源管理函数传到应用服务器，供应商就可以运用复杂的升级算法。

可访问资源管理系统：利用ejb容器，你可以获得成千上万行的代码来访问和管理资源，包括事务管理系统，安全管理系统和目录服务。没有ejb的话，你只能自己实现这些组件。

缺点

大量复杂的规范：对于描述一个复杂分布式系统的规范来说这是很正常的，但是并不是里面的所有信息都需要编码，这使得规范成为一个很不方便的工具。

庞大的文档：在开始开发一个项目之前，你通常需要阅读1000多页的文档，这是部署ejb的很令人畏惧的原因之一。

增加了开发时间：ejb解决方案比普通java代码实现要求更多的时间。调试ejb代码需要的时间也要比调试普通java代码长。主要原因是因为你不能确定漏洞是在你的代码中还是在容器中。

ejb代码更复杂：例如，为了实现一个会话bean，你必须编写三个类，一个登录bean，你必须编写四个类。添加一两个部署描述符和一个最简单的“hello world”应用就会生成10个文件而不是一个文件。

重复设计的危险：这是规范复杂性的后果。如果你没有很好的理解ejb的概念，你就不能有效地使用该技术，而且你还可能把项目变得比实际需要的更复杂。

规范改变：ejb是一项新兴技术，你的代码潜在地存在过时的风险，这就要求增加额外的工作和投入来使得它与新的ejb容器兼容。

什么时候你可能想要使用ejb

假设你有一个使用数据库的简单servlet web应用。你使用jdbc从你的应用访问数据库。作为一个sql查询的结果，你会得到拥有一些数据的结果集resultset，这些数据代表了你的业务对象。

这种方法使用数据不是很方便。你需要创建一个java类表示一个数据库结构，你的代码可能如下所示：

myobjectobj = new myobject();

obj.setxxx(rs.getstring("xxx"));

obj.setyyy(rs.getstring("yyy"));

在将结果集换成对象表示与返回后，你需要考虑如何将这个逻辑转移到myobject中。为了将servlet从jdbc访问细节中分离出来以及不在直接使用java.sql.*包中的类，你应该让该对象可以在数据库中找到自己，然后修改或删除它。

现在又有另外一个问题：如何通过某些查询找到数据库中的一个对象？如果你需要通过主键找到它，那么你需要将主键传给类构造函数即可。如果你需要通过某些准则查找，这将需要很多专用静态方法。如果需要的话，你可能还需要支持事务处理和滚回的方法。

当你的应用程序获得广泛应用时，正常运行时间百分比和可用性将变得十分重要，这时你会需要复制，快速对象持久性，对象高速缓冲区，数据库连接池，安全事务等等。

所有这些问题都可以由实体企业级java beans解决。你不会再犯许多程序员已经犯过的错误。如果你的bean是一个容器管理持久性bean，那么你只需要实现一两个接口，而不必考虑必须访问的数据库。如果不能完全满足你的需要，也没有问题，你可以使用bean 管理持久性(bmp)实体自己实现持久性。

在你的应用程序业务域中，对象不仅保存数据，还有一些行为。这些行为代表业务逻辑。当你开始编写应用时，所有业务逻辑都存放在servlet中，所以你的应用需要一些servlets的支持。

你可以选择是复制粘贴业务逻辑代码，还是将它放在独立的类中。最后，可能有些用户要求在不同的web页面中与你的应用进行交互，你需要保存每个用户请求之间的会话信息。解决这个问题的方法称为会话bean，它封装了你的应用中的所有业务逻辑，它可以是有状态的或是无状态的。

什么时候你可能不想选择ejb

ejb确实是一项很好的技术，但是它并不是一个通用解决方案。ejb提供的很多特性（像安全性、持久性和事务支持）并不是每个应用都需要。

此外，在非分布式应用中你也可能不想使用ejb，因为这种程序速度可能比安全和事务处理更重要。由于ejb的分布式本质，为了便于在客户端和ejb组件（或服务器）之间进行通信，数据必须先进行某种处理（串行化）然后再进行反处理（串行数据并行化）。这导致了大量的开销，使得性能下降，这也是为什么使用jvm（java虚拟机）中的本地类可能更好些的原因。

关于ejb的几种错误观念

ejb是一项昂贵的技术：这种说法部分正确。但最近已经发布了几个低价位或免费的应用服务，这些应用服务具有商业服务器的所有功能。在一个大型企业应用项目中，应用服务器的花费只是整个项目开销中很小的一部分。

如果使用cmp beans，你就不需要sql相关知识：这是不正确的。

ejb应用便于在不同的容器之间移植：这种观点部分正确。ejb代码只有在以可移植的方式编写时才能移植。会话beans和bmp beans可以很容易的移植，但是移植cmp beans需要大量的工作。

实体beans工作速度缓慢：基本上是正确的。实体beans确实运行很慢，而且很多情况下，最好将它们转换成会话beans。

结论

对于你的项目在做出是否使用ejb技术决定之前，你需要理解你的应用的所有需求，它的演化前景以及ejb的主要目标和缺陷。