什么是业务逻辑和数据库的访问？
业务逻辑和数据库访问决策
这里有2种完全不同的方法来设计JAVA企业程序，其中一种选择是采用标准EJB2实现途径（approach）。我更愿意称这种方法为重量级实现途径，当你使用重量级实现途径时你需要用会话beans（session bean）和消息驱动 beans（message-driven bean）去实现业务逻辑。 你也可以使用DAOs（data access object）或者实体bean去访问业务逻辑
另外一种选择是使用POJOs 和轻量级构架，这种方式我称为POJO实现途径。当使用POJOs实现途径时，你的业务逻辑完全由POJO来实现。 你可以使用持久型构架又叫做对象/关...全部
业务逻辑和数据库访问决策
这里有2种完全不同的方法来设计JAVA企业程序，其中一种选择是采用标准EJB2实现途径（approach）。我更愿意称这种方法为重量级实现途径，当你使用重量级实现途径时你需要用会话beans（session bean）和消息驱动 beans（message-driven bean）去实现业务逻辑。
你也可以使用DAOs（data access object）或者实体bean去访问业务逻辑
另外一种选择是使用POJOs 和轻量级构架，这种方式我称为POJO实现途径。当使用POJOs实现途径时，你的业务逻辑完全由POJO来实现。
你可以使用持久型构架又叫做对象/关系映射构架（a。k。a=also know as ）例如Hibernate 或者 JDO来访问数据库，再用Spring AOP（面向层面编程）来提供企业服务，比如事务管理和安全。
EJB3由于融合了POJOs和其他一些轻量级概念，所以对两者（指轻量级和重考锻揪叮┑那�分不是很清楚。举个例子，POJO中的实体bean既可以再EJB容器内运行，也可以再EJB容器外运行，然而POJOs中的会话bean和消息驱动bean仍然有重量级的行为，因为他们只能在EJB容器内部运行。
所以，显而易见的，EJB3既是重量级的又有POJO的特性。EJB3中的实体bean是轻量级实现途径中的一部分。
在开发过程中，首要的是从各种各样的设计中选择到底采用重量级实现途径还是采用POJO实现途径。
决策可以影响程序的几个方面，包括业务逻辑结构和数据访问机制。为了帮助从两种实现途径中择其一，来看这张典型的企业应用程序结构图，结构图在图示1中，而且在设计过程中就必须判断到底使用那种策略。
Figure 1。
A typical application architecture and the key business logic and database access design decisions。
程序由网络基本表示层、业务层、持久层组成。网络基本表示层负责HTTP请求和为一般的浏览器客户端、XML和其他的胖体客户端生成HTML，比如为Ajax基本客户端生成HTML。业务层被表示层调用，用来实现程序业务逻辑。
持久层被业务逻辑层用来访问外部数据源，比如数据库和其他程序。
表示层的设计不在本篇文章讨论之内，来看图表的其他部分，我们需要决定业务层结构的接口，这个接口是提供给表示层以及其他客户端的。而且还需要决定怎样访问能供多个程序访问的数据库。
我们还必须决定如何处理短期事务处理事务和长期事务处理事务的并发问题。这些加起来一共有5种决策。每种决策都是要设计者来制定，为了能看懂演示图（big picture）要求每个开发者也都了解这些策略。
这些决策直接决定程序业务和表示层设计的特点。当然，还要决定一些其他很重要的决策。比如业务处理（transactions）、安全问题、缓存问题以及如何整合程序，但是关于这些问题通常在其他文献中讨论在图表1中显示的五种决策，每种决策都有多种选择。
每种选择根据它要解决的实际问题都有相应的优缺点。后续章节中，你会发现每种决策针对一个或多个领域时，在功能性、易开发性、可维护性和可用性方面有不同的平衡点。尽管我是POJO实现途径的超级大FANS，但是仍然需要了解其优缺点，以便于为你的程序做最好的选择下面我们来了解一下每种决策的大纲和其选项。
决策1：组织业务逻辑
现在，很多的注意力都集中在某项技术的优点和缺点，尽管这很重要，但是在本质上你需要了解如何建构你的业务逻辑。如果不考虑如何组织就去写代码是非常简单的。例如，为一个会话BEAN添加代码要比在域模式（domain model。
： An object model of the domain that incorporates both behavior and data。）中判断应该添加那种新特性要简单的多。理论上你仍然需要刻意的为你的软件设计最合适的业务逻辑。
毕竟我相信你有过修改别人垃圾结构代码的惨痛经验
关键的决策是：到底应该用面向对象的实现途径还是面向过程的实现途径来实现你的程序。这个不是关于技术的决策，但是你技术上的决策可以潜在的约束你的业务逻辑的组织结构。
采用EJB2技术，有利于面向过程设计，然而POJOs和轻量级构架可以让你为特殊的程序选择最好的实现途径
采用过程式设计
虽然我是一个面向对象实现途径（指前文的使用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或者其他非面向对象语言的话，你应该用过这种设计模式。如果这种模式很适合你的设计的话，用这种模式设计也是一种不错的选择。
这种直观的过程式开发途径，非常的诱人，因为你只需要写代码就好了，不用考虑如何组织你的类文件。
但问题是，如果你的业务逻辑非常的复杂，那么你的代码会变的噩梦般的难以维护。所以，除非你要写的程序非常的简单，否则你应该用面向对象设计你的程序，而不要受面向过程的代码的诱惑。
采用面向对象设计
在面向对象设计中，业务逻辑是由对象模型构成的，对象模型是由许多小类组成的关系网。
这些类直接体现的是问题域的解决方法，如图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所说的表模型设计模式。这种模式比事务处理脚本模式更加的结构化，因为它为数据库中的每个表都写了一个类，而这个类中实现了所有对这个表的操作代码，这个类就是表模型类。
（我的解释就是为每个表专门写个类，对表的所有操作，全都由这个类中的方法实现，相当于用一个类模拟的数据库中的表）。和事务处理脚本模式相比，它将数据和行为分别封装到了不同的类中，因为表模型类的实例相当于真实数据库中的数据，这当然要比单独的一条记录要好的多。
最后，可维护性成了问题，然而表模型设计模式还是有一些好处的。收起
