JavaBean应用正源

JavaBean应用正源

Sun公司在JavaEE规范中,提供了JSP以及Servlet两项影响深远的Web开发技术。并提供了两种应用方式上的建议：Model1和Model2。Model1指的是Jsp+JavaBean；Model2指的是Jsp+Servlet+JavaBean。

在上述两种应用模式中，都有一个关键的角色JavaBean。那么，JavaBean到底扮演了那些角色，每种角色的作用是什么哪，JavaBean在实际的应用中有哪些注意事项，其未来发展前景是什么样的那？

在上述两种模式中，都包括两种类型的JavaBean。一种是数据传出Bean，另外一种是业务处理Bean。

第一：数据传输Bean

所谓的数据传输Bean，用以收集客户端提交的数据，并通过Bean在模型，控制组件之间进行数据传递。在今天的软件开发中，这一角色有一个专有名词叫数据传输对象（DTO:Data Transfer Object）同时，他的传输范围也不仅仅局限于控制组件与模型之间，在分层体系架构开发下，各层之间的数据传递，都可以通过DTO来完成，以降低各层之间的耦合度。

那么JavaBean来做数据传输对象的解决方案，是否是理想的哪？就个人观点而言，十分不理想！原因有如下两点：

首先客观上造成了类爆炸，不利于项目维护。

一般来说，一个项目的运行，离不开数据的传入过程：将用户提交的数据传输给数据操作层，用来完成数据的检索和更新；数据传出过程：将查询结果带出交给页面负责显示。

就数据数据传入的过程而言，需要有一个Bean用来收集客户端提交的数据；而当进行数据查询完毕，解析结果集的时候，为了能把结果集中的数据带出来交给页面显示，又不得不针对每个查询都构造一个Bean，用以保存数据。而实际的项目开发过程中，数据查询用到的是最多的，会有多少个SELECT？上帝也搞不清楚。这样，无论是某一个功能点还是整个项目中，为了完成数据传书而构建的Bean必然会很多。当项目进入维护期，既要维护功能点，同时为了适应页面项目以及查询项目的变化，又要维护这些传输Bean，我们真的好辛苦，心，也真的好苦啊！

此处需要补充的一点是，在Sturts1.x中,数据传输Bean实际上已经演化成FomrBean。但是FormBean的设计上是存在缺陷的，既：内部包含了一个request对象和response对象。此时他已经不在是单纯的POJO了。而是一个为特定Action编写的，用以获取页面数据的，带有一定侵入性并且包含Struts特定功能的，功能性处理类。而如果将FormBean作为DTO传递到BO中，造成BO对显示层的严重依赖，这样，一方面破坏了Model2通过通过控制器分离模型和视图的本意，也就必然影响BO的可复用性以及可维护性。为了解决这个问题，好多人的做法是，再构造一个与FormBean包含相同属性的POJO，然后将FromBean的数据通过好的或者笨劣的方式传递到这个POJO中。但是，当一旦增减项目页面的时候，你需要同时FromBean以及这个POJO。这样，无疑促使整个项目中，数据传书Bean的数量进一步爆炸，使得项目的维护，雪上加霜！

其次,不利于提取DAO(数据访问对象),BO(业务逻辑对象)的公用抽象层.

一般来说，软件运行过程中，离不开的操作不外乎是：数据检索，数据更新，数据计算这三个方面。基于此，我们完全可以提取技术抽象层。构建DAO公共接口，BO公共接口，公共控制器组件。然后，让整个程序宏观调度，完全基于抽象层来完成。然后，基于抽象层再去编写实现类。这样，会大大降低系统的耦合度，提高项目的可维护性，降低维护成本，也就可以让更多的人，干更多的事儿，从而为公司赚来更多的利润！

但是，为了实现这个目标，就必须做到两点。一个是：方法能接收一切客户端数据；另一个是：方法接收数据的格式，能适应一切功能点。无论业务怎么变化，接口中定义的方法都能适应。这就要求方法参数，能有共性，具有统一的接口，可以将一切传入数据，应用统一的方式进行封装，同时又方便读取，这个读取的复杂度，绝对不能高于应用Bean做DTO。

而应用JavaBean来作为数据传入过程的参数，显然无法达到这个要求！因为我们没有办法抽象一个能表示所有JavaBean的所有属性的类。

再次.对页面项目变化的适应能力差

DTO中封装的属性，对应于页面端的数据控件，只要页面有一个有一个控件，DTO中就应该包含这个属性的名称和值。而对于一个项目来说，无论开发期还是系统维护期，页面输入项目的变化，都会存在。这个是由客户不成熟性和企业不成熟性共同决定的。这里不多言，相信做过实际开发的程序员都有体会。而好的DTO解决方案，应该能适应这种动态变化，而无序重构。

JavaBean作为DTO，显然满足不了这个要求，自然也就无法适应负责多变的企业开发！

写到此处，笔者已经把JavaBean作为数据传书对象贬的一无是处，那么，我也有责任提出相对较好的替代方案，要不，有人会怀疑我天桥耍把势了。

其实个人认为，理想的方案，非常简单，应用Map替代JavaBean，做数据传输对象，上述问题，都会迎刃而解，不再是问题！而此时，客户端提交的数据，通过提取系统公共服务以后，实际应用的时候，只需要一句话，就可以封装到Map中，而一个良好的架构，开发人员已经不需要管理DTO的生成过程和传递过程，直接实用就可以了。生活，毕竟能变得美好一些了！

第二：业务处理Bean以及JavaBean未来的走向分析

JavaBean除了用以方装数据，还可以包含一定的方法，一般来说，如果不涉及分布式运算，完全可以应用JavaBean充当业务处理类，也就是所谓的模型。而近些年，软件开发更加提倡的理念是非侵入性和独立测试。此时JavaBean更见其功效。同时人们也提出，实用没有任何限制，没有任何规范的普通Java类来充当业务模型，以便更好地解决架构耦合，侵入性以及独立测试的问题，为此，人们给普通Java类，起了个现在耳熟能详的名字：POJO。随着POJO概念的兴起，以及人们编程艺术的提高，JavaBean的原有规范也在逐步的被淡化，而是日渐走向于POJO的融合之路。连原先繁琐负责的要命的EJB（企业级JavaBean）技术，在这一强劲的势头下，也不得不作出妥协，并且开始朝着POJO的方向努力，可喜的是，她已经迈出了成功的一步，这就是EJB3.0。

而程序发展到Spring阶段，“Bean”的范围已经进一步扩大，但凡能被实例化或是能被JNDI查找到，都可以称为是Bean。

无论Bean也好，JavaBean或是POJO也罢，在实际的应用中，最好还是有一个无参构造子，属性的命名上，最好遵循“字母和数组组成，必须以字母开始，头两个字符，必须都是英文字母，并且大小写统一。”这里我都建议是，属性中的全部英文字母，要么全部小写，要么全部大写，这将方便于，目前主流架构中普遍应用的通过反射机制读写数据。

以上，是个人对于JavaBean应用的一些总结，欢迎交流！