30

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.

Community
  • 1
  • 1
Kevin Loney
  • 7,483
  • 3
  • 28
  • 33

1 Answers1

39

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 );
Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • Thanks, after a significant amount of reading and pondering the light went on. – Kevin Loney Jan 13 '09 at 07:19
  • Thanks for great explanation of what's the difference between them. – BinaryButterfly Nov 22 '09 at 17:32
  • @BillKarwin Should data table entities **(defined in the business layer, BL)**, e.g. "User" or "UserProfile" here, have any data access concerns? For example, if the Data Access uses attribute based mapping to materialize objects on data access. Should the BL data table entities carry those attributes? Would it not couple BL to data access specifics? I am trying to establish the relationship between BL and DAL in a table module implementation. – Umair Ishaq Oct 11 '13 at 19:14
  • @fallow, eventually you have to have *some* class that knows how to access the data in the way you store it. Remember that the purpose of creating "layers" in OOP is to preserve the flexibility to swap out different implementations. If you don't have that need, then creating more abstractions and layers has little value. – Bill Karwin Oct 11 '13 at 20:18
  • @BillKarwin Thank you very much for your comment. To be clear, you are **NOT suggesting combining BL and DAL** if the flexibility is not required. You **ARE** suggesting that having those attributes in the BL entities might be a suitable compromise; correct? – Umair Ishaq Oct 11 '13 at 21:12
  • @fallow, it's hard to make a generalization without knowing the requirements of the project. But it's typical to make a **BL** class use a **DAL** object -- [favor HAS-A over IS-A](http://en.wikipedia.org/wiki/Composition_over_inheritance). – Bill Karwin Oct 11 '13 at 21:39