b.Table Module

  1. Motivation
    1. To have a single instance that handles the business logic for all rows in a database table or view.
  2. Summary
    1. A Table Module organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data.
    2. It is mapping of one business object to one table and much closure to Simple Domain Model.
    3. Unlike domain model it it does not have inheritance relationship.
    4. Usually Table Module normally uses a Record Set (508) that mimics a SQL table. 
    5. Multiple table module can use same record set.

  3. When to Use
    1. When domain logic is simple and data is in tabular form.
  4. Related Patterns
    1. Table Data Gateway 
      1. The Table Module may include queries as factory methods. The alternative is a Table Data Gateway, but the disadvantage of this is having an extra Table Data Gateway  class and mechanism in the design. 
      2. he advantage is that you can use a single Table Module on data from different data sources, since you use a different Table Data Gateway for each data source. 
  5. Related Technologies 
    1. TODO
  6. Specific Considerations 
    1. Table Module Vs Domain Model
      1. If the objects in a Domain Model and the database tables are relatively similar, it may be better to use a Domain Model that uses Active Record. 
      2. Table Module works better than a combination of Domain Model and Active Record when other parts of the application are based on a common table-oriented data structure. 
      3. In table Module you can't have direct instance-to-instance relationships, and polymorphism doesn't work well. So, for handling complicated domain logic, a Domain Model is a better choice.
  7. References
    1. http://martinfowler.com/eaaCatalog/tableModule.html