XoopsObject & XoopsObjectHandler

XOOPS' early data persistence architecture was based on the Data Mapper pattern, with two abstract classes to aid in the class development XoopsObject and XoopsObjectHandler

• XoopsObject: abstract class of Data Object

• XoopsObjectHandler: Mapper. An abstract class that saves XoopsObject in DB or rebuilds XoopsObject from DB

The idea behind them is that a class can extend XoopsObject to describe an object, whereas extending XoopsObjectHandler will give more like an interface for handling the objects, i.e. get, insert, delete and create objects.

E.g. for a ThisObject class, you can make a ThisObjectHandler to get, insert, delete and create ThisObject objects.

The advantages of extending these two classes are for XoopsObject:

• Automatic access (inheritance) to methods, easing the assignment/retrieval of variables

• Automatic access to methods for cleaning/sanitizing variables

and for XoopsObjectHandler:

• A place to put all those functions working with more than one object i.e. (e.g. a "getAllObjects()" function).

These functions will become easier to track down in the file system (since they are connected to a class, it is just a matter of finding the class and not going through the function files in the module/core/PHP native in search for it.

An additional idea is that the XoopsObjectHandler-extending class should be a Data Access Object, i.e. the class, which handles database calls - and leaving the XoopsObject-extending class to have object-describing methods, such as methods which handle and manipulate variables, calling methods on the handler for retrieving, updating and inserting data in the database.

In XOOPS 2.3 we've added a new enhanced version of the XoopsObjectHandler, the XoopsPersistableObjectHandler, that incorporated features/characteristics from the Repository Pattern