Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Table Module vs. Domain Model

I asked about Choosing a method to store user profiles the other day and received an interesting response from David Thomas Garcia suggesting I use the Table Module design pattern. It looks like this is probably the direction I want to take. Everything I've turned up with Google seems to be fairly high level discussion, so if anyone could point me in the direction of some examples or give me a better idea of the nuts and bolts involved that would be awesome.

like image 501
Kevin Loney Avatar asked Jan 11 '09 22:01

Kevin Loney


People also ask

What is a table module?

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.

How is domain logic organized within a table module?

Table Module. The next design pattern for organising domain logic is Table Module. It presents a database-centric approach, with all the business logic organised around database tables. In Table Module a single class encapsulates all the domain logic for all records stored in a table or view.

What is domain model pattern?

Domain model pattern provides an object-oriented way of dealing with complicated logic. Instead of having one procedure that handles all business logic for a user action there are multiple objects and each of them handles a slice of domain logic that is relevant to it.

What is a domain logic?

In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed.


1 Answers

The best reference is "Patterns of Enterprise Application Architecture" by Martin Fowler:

Here's an excerpt from the section on Table Module:

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. The primary distinction with Domain Model is that, if you have many orders, a Domain Model will have one order object per order while a Table Module will have one object to handle all orders.

Table Module would be particularly useful in the flexible database architecture you have described for your user profile data, basically the Entity-Attribute-Value design.

Typically, if you use Domain Model, each row in the underlying table becomes one object instance. Since you are storing user profile information in multiple rows, then you end up having to create many Domain Model objects, whereas what you really want is one object that encapsulates all the user properties.

Instead, the Table Module makes it easier for you to code logic that applies to multiple rows in the underlying database table. If you create a profile for a given user, you'd specify all those properties, and the Table Module class would have the code to translate that into a series of INSERT statements, one row per property.

$table->setUserProfile( $userid, array('firstname'=>'Kevin', 'lastname'=>'Loney') ); 

Likewise, querying a given user's profile would use the Table Module to map the multiple rows of the query result set to object members.

$hashArray = $table->getUserProfile( $userid ); 
like image 113
Bill Karwin Avatar answered Oct 06 '22 00:10

Bill Karwin