J2EE中的业务逻辑和数据库访问决策说明 - 编程入门网

采用过程式设计

虽然我是一个面向对象实现途径(指前文的使用POJO和LIGHTFRAMEWORK)的倡导者，但是有些情况下面向对象实现途径有些大材小用，比如你只想实现一个非常简单的业务逻辑。而且，有时候，面向对象实现途径不太可行-―比如，你没有持久层构架来将你的对象映射到数据库中，在这种情况下，更好的方法是编写面向过程的代码，而且采用Martin Fowler称作事务脚本(Transaction Script)的设计模式，要比采用面向对象实现途径设计要好，因为你只需要写一个方法来调用事务处理脚本去处理表示层的请求。

采种这种实现途径的一个很重要的特点是，用于实现某种行为的类和数据存储区是分开的。在EJB2的应用程序中，这种方式的业务逻辑和图表2中的设计是非常相似的。这种设计的核心全都集中在EJB或者POJO的行为上，因为他们实现了事务脚本，并且还操作那些 “哑”对象数据(因为他们只拥有很少的行为，大部分都是数据)。因为大部分的行为都集中在少量的大型类上，所以代码会变的很难理解与维护。

Figure 2. The structure of a procedural design： large transaction script classes and many small data objects

这种设计具有高面向过程的特性，而且基本不依靠面向对象语言的特性。如果你曾经使用过C或者其他非面向对象语言的话，你应该用过这种设计模式。如果这种模式很适合你的设计的话，用这种模式设计也是一种不错的选择。

这种直观的过程式开发途径，非常的诱人，因为你只需要写代码就好了，不用考虑如何组织你的类文件。但问题是，如果你的业务逻辑非常的复杂，那么你的代码会变的噩梦般的难以维护。所以，除非你要写的程序非常的简单，否则你应该用面向对象设计你的程序，而不要受面向过程的代码的诱惑。

J2EE中的业务逻辑和数据库访问决策说明(2)

采用面向对象设计

在面向对象设计中，业务逻辑是由对象模型构成的，对象模型是由许多小类组成的关系网。这些类直接体现的是问题域的解决方法，如图3所示，在这种模式中，有些类只有数据，有些类只有行为，但是大多数的则两者都有，这是优秀的类设计的一种特点。

Figure 3. The structure of a domain model： small classes that have state and behavior

面向对象设计有许多的好处，包括可以提高可维护性和可延展性。你可以用EJB2的实体bean来实现一个简单的对象模型。但是如果像要获得更多的好处的话，必须要使用POJOs技术和轻量级持久层构架――比如Hibernate和JDO技术。POJO可以让你开发丰富的模型，这些模型可以拥有继承和回调等特点。而轻量级持久层构架可以让你很简单的从对象模型映射到数据库。

对象模型的另外一个名字是域模型，Fowler称这种由面向对象途径来开发的业务逻辑叫做域模型设计模式。(就是类的设计是直接用来解决问题的，则这种设计模式叫做域模型设计模式)

表模型设计模式

我曾经一直用域模型和事务处理脚本模型设计应用程序。但是有一次我听说JAVA企业应用程序可以用第三种途径来实现，这种途径就是Fowler所说的表模型设计模式。这种模式比事务处理脚本模式更加的结构化，因为它为数据库中的每个表都写了一个类，而这个类中实现了所有对这个表的操作代码，这个类就是表模型类。(我的解释就是为每个表专门写个类，对表的所有操作，全都由这个类中的方法实现，相当于用一个类模拟的数据库中的表)。和事务处理脚本模式相比，它将数据和行为分别封装到了不同的类中，因为表模型类的实例相当于真实数据库中

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!