Developer Guide: Data Access Objects (DAO's)

All of ThinkUp’s database interactions are encapsulated in DAO’s (Data Access Objects), contained in the model (the model directory).

DAO Method Interfaces

What all DAO methods should return:

• INSERT Single item: last inserted ID (where there is an AUTO_INCREMENT primary key)
• INSERT Multiple items: number of inserted rows
• UPDATE/DELETE: number of affected rows
• SELECT Multiple rows: array with objects, or arrays if no appropriate class exist, empty array on no rows returned.
• SELECT Single row: object, array if no appropriate class exist, null on no rows returned.
• IF: True if the data exist, otherwise false.

As seen above multiple SELECT formats does exist:

• “SELECT Single row” is for methods that expect only/exactly one result.
• “SELECT Multiple rows” is for methods expecting any number of results. Will not return “SELECT Single row” format upon 1 row returned.

Method naming conventions

Names according to function

getData* Data Parsing Methods used internally in DAO, do not use this namespace for data accessing.
get* (e.g. getUsersByID) SELECT queries – It is encouraged that you try to use the noun in Singular or Plural according to single or multi-row return.
set* (e.g. setActive) UPDATE Queries
add* (e.g. addUser) INSERT Queries – It is encouraged that you try to use the noun in Singular or Plural according to single or multi-row insert.
delete* (e.g. deleteUser) DELETE queries
is* (e.g. isActive) IF check returns boolean, i.e., if ($user_dao->isUserActive($id)) or if ($post_dao->isPostInStorage($id))
count* (e.g. countUsers) Returns integer with the item count.

Reserved functions

insert – takes an object as argument, and inserts it to the table.
save – takes an object as an argument, and stores the data in it back to data backend
poke – Takes an ID as argument, “pokes” the record (sets “last seen” or whatever to now), returns update count (usually 1)

Other things to remember

As the storage Backend may or may not be a “database”, it would be encouraged not to create methods with names that imply that the backend is using a database.
However at this time this is not enforced.

Return objects/classes

When you create a class to contain return data, make sure to make the construct so it can handle no-data-input.
Some return methods slipstreams the data directly into the properties, but the construct is still called with no arguments.
For classes that expect arbitrary (no-standard) data, try overloading