Table module pattern
Line 3: | Line 3: | ||
The Table Module pattern introduces a single object to handle all the requested action towards a database table or view. It combines the data and behavior in one class and also keeps a tight linkage with relational database. An instance of the Table Module object looks like a regular objects, but in fact it does not have hold the identity which the object is currently working with. The difference between Domain Model and Table Module is that, for Domain Model, several object instances will be used to deal with different records of the database table; however, with Table Module, only one object will be used and it deals with all records of the database table. | The Table Module pattern introduces a single object to handle all the requested action towards a database table or view. It combines the data and behavior in one class and also keeps a tight linkage with relational database. An instance of the Table Module object looks like a regular objects, but in fact it does not have hold the identity which the object is currently working with. The difference between Domain Model and Table Module is that, for Domain Model, several object instances will be used to deal with different records of the database table; however, with Table Module, only one object will be used and it deals with all records of the database table. | ||
− | + | ==== When to Use It ==== | |
The Table Module is best to be sued with table-oriented data. It also push the data structure to the center of the application, which makes easy for programmer to access the data structure. The drawback of the Table Module is that it does not have the full power of objects when dealing with complex business logic. In such a case, the [[Domain model pattern]] with [[Active record pattern]] is a better choice. If the application only use few shared common table-oriented data structure, then the Table module pattern is better than the combination of [[Domain model pattern]] and [[Active record pattern]]. | The Table Module is best to be sued with table-oriented data. It also push the data structure to the center of the application, which makes easy for programmer to access the data structure. The drawback of the Table Module is that it does not have the full power of objects when dealing with complex business logic. In such a case, the [[Domain model pattern]] with [[Active record pattern]] is a better choice. If the application only use few shared common table-oriented data structure, then the Table module pattern is better than the combination of [[Domain model pattern]] and [[Active record pattern]]. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Latest revision as of 03:23, 25 November 2010
The short definition for the Table Module Pattern is: “a single instance that handles the business logic for all rows in a database table or view”.
The Table Module pattern introduces a single object to handle all the requested action towards a database table or view. It combines the data and behavior in one class and also keeps a tight linkage with relational database. An instance of the Table Module object looks like a regular objects, but in fact it does not have hold the identity which the object is currently working with. The difference between Domain Model and Table Module is that, for Domain Model, several object instances will be used to deal with different records of the database table; however, with Table Module, only one object will be used and it deals with all records of the database table.
When to Use It
The Table Module is best to be sued with table-oriented data. It also push the data structure to the center of the application, which makes easy for programmer to access the data structure. The drawback of the Table Module is that it does not have the full power of objects when dealing with complex business logic. In such a case, the Domain model pattern with Active record pattern is a better choice. If the application only use few shared common table-oriented data structure, then the Table module pattern is better than the combination of Domain model pattern and Active record pattern.