Table Module
A single instance that handles the business logic for all rows in a database table or view.
For a full description see P of EAA page 125
One of the key messages of object orientation is bundling the data with the behavior that uses it. The traditional object-oriented approach is based on objects with identity, along the lines of Domain Model (116). Thus, if we have an Employee class, any instance of it corresponds to a particular employee. This scheme works well because once we have a reference to an employee, we can execute operations, follow relationships, and gather data on him.
One of the problems with Domain Model (116) is the interface with relational databases. In many ways this approach treats the relational database like a crazy aunt who's shut up in an attic and whom nobody wants to talk about. As a result you often need considerable programmatic gymnastics to pull data in and out of the database, transforming between two different representations of the data.
A Table Module organizes domain logic with one class per table in the data-base, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model (116) is that, if you have many orders, a Domain Model (116) will have one order object per order while a Table Module will have one object to handle all orders.
用一个单独的实例来处理数据库表或视图中所有行相关的业务逻辑
面向对象的关键思想就是将数据和使用数据的行为封装到一起。传统的面向对象方法是基于对象的标识，在领域模型中就是如此。因此如果我们有一个Employee类，他的任何实例对应一个特定的雇员，这种方法能够很好的工作，因为一旦我们拥有一个Employee对象的引用，我们就可以执行他的操作，追踪关联对象，还可以收集他的数据。
领域模型的一个问题就是和关系数据库的接口。在很多情况下，领域模型模式下处理关系数据库就像被关到阁楼里的泼妇，没人想惹！结果要把数据存入取出数据库你常常需要大量的编程训练。在两种不同的数据表现形式之间转换！
表模块用每个数据库表一个类的方法组织业务逻辑，而且一个类的实例包含在数据上的各种操作。和领域模型主要的区别就是，如果你有许多订单，领域模型下会每个订单一个对象，而表模块下是一个对象处理所有订单！
