3、表模組

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對象的引用，我們就可以執行他的操作，追蹤關聯對象，還可以收集他的資料。

    領域模型的一個問題就是和關聯式資料庫的介面。在很多情況下，領域模型模式下處理關聯式資料庫就像被關到閣樓裡的潑婦，沒人想惹！結果要把資料存入取出資料庫你常常需要大量的編程訓練。在兩種不同的資料表現形式之間轉換！

    表模組用每個資料庫表一個類的方法組織商務邏輯，而且一個類的執行個體包含在資料上的各種操作。和領域模型主要的區別就是，如果你有許多訂單，領域模型下會每個訂單一個對象，而表模組下是一個對象處理所有訂單！