I'm using strategy pattern for a PHP project which roughly looks like this. I've been reading this book as reference for making the design pattern.
I'm able to do simple inserts, updates or fetches from the database using the "Insert", "Search", "Update" concrete strategy classes on single tables.
However when it comes to a complex query like JOINs or VIEWs with multiple tables, these classes aren't sufficient.
How do I make a strategy class which allows me to retrieve custom no. of columns from two or more tables using JOINs or VIEWs? OR alternatively should I use stored procedures instead?
Currently, each concrete strategy class looks like this:
interface IStrategy {
public function algorithm(AbstractModel $modelObj, $tablename);
}
class InsertStrategy implements IStrategy{
public function algorithm(AbstractModel $modelObj, $tablename){
// construct SQL statement
// Initialize the Database Object
// Insert data using PDO
}
}
My approach for your usual run of the mill business apps is to avoid the "table API" approach and create a "data API" using stored procedures. You can use views to support your SPs too.
So rather than CRUD, write SPs that provide useful chunks of data to your business layer. Do all the filters, groups, sorts etc. that you can in your SP and get the PHP business layer to do the businessy stuff. You can usually access all your SPs thorough your usual data access layer (or ORM at a bit of a stretch of the imagination).
Separating your data preparation behind SPs is analogous to hiding your business layer behind a service. The reasons and benefits all stack up just as well.