Dit antwoord is afhankelijk van de huidige querystructuur, waar geen voorwaarden zijn
class CategoriaDAO extends PDOConnectionFactory
{
/*DB Connection, static member since you only need one connection*/
private static $dbConnection;
/*Sql result set, static since there is not conditonal and only a single table used*/
private static $resultSet;
private static function getConnection()
{
/*Connect to mysql db, set CategoriaDAO::dbConnection; */
}
private static function populateResultSet()
{
/*Run query and populate resultSet - either as sql result or parse to array - your call*/
}
/**
*
* @var PDO $conn
*/
private $conn;
public function __construct()
{
/*Get sql connection if one hasn't already been established*/
if(!CategoriaDAO::dbConnection)
$this->conn = PDOConnectionFactory::getConnection();
}
}
De gedachte hierachter is dat, aangezien de resultaten altijd hetzelfde zullen zijn (negeren, bijwerken, invoegen, verwijderen voor nu), er geen vereiste is om een kopie van de resultaten in elk object te bewaren.
Zoals u aangaf, zullen tabelupdates de opgeslagen resultaten niet synchroon laten lopen met het object; dit is waar ik een beetje terug zou willen gaan en zeggen dat als de resultatenset voor een bepaald object alleen up-to-date hoeft te zijn op het moment van creatie, gebruik dan normale objectleden.
Het is ook de moeite waard om zowel onafhankelijk als in combinatie met de vorige opmerking te overwegen of de query al dan niet zal veranderen en als dit het geval is, moeten er objectleden worden gegenereerd. Als de zoekopdracht niet verandert, hoeft u zich geen zorgen te maken - behalve het vorige punt. Als het verandert, worden uw opties min of meer behandeld in de volgende voorbeelden.
class Foo{
private $someMember;
/*
$params = Associative array of fields and values
*/
private static buildAndRunQuery($params)
{
/*Build sql query based on the given params Array()*/
}
public __construct($someMemebrValue)
{
$this->someMember = $someMemberValue;
Foo::buildAndRunQuery(Array("fieldName" => $this->someMember));
}
}
In dit voorbeeld gebruikt u nog steeds een statische methode om de query te genereren, maar u geeft niet-statische leden door voor het proces. Op dit punt (zie opmerking over objecten die up-to-date zijn op het moment van maken) kunt u de resultaten binnen het statische lid of geef ze terug aan de functie __construct() en sla deze op in de objectinstantie.
Dan is er het potentieel dat de query die u gebruikt een beetje meer betrokken is dan alleen het aanvragen van bepaalde velden, zodat het maken van een multidimensionale array om door te geven aan de statische functie meer gedoe zou zijn dan het waard is. In dat geval zou u de buildAndRunQuery() kunnen splitsen in buildQuery() - instantiemethode en runQuery() statische methode zoals.
class Foo{
private $someMember;
/*
$params = Associative array of fields and values
*/
private static runQuery($query)
{
/*Build sql query based on the given params Array()*/
}
private function buildQuery()
{
/*Construct your query here and either return calling method or store in instance member*/
/*Either*/
return <Constructed query>;
/*Or*/
$this->query = <Constructed query>;
}
public __construct($someMemebrValue)
{
$this->someMember = $someMemberValue;
/*As per buildQuery() comment either:*/
Foo::runQuery($this->buildQuery());
/*Or*/
Foo::runQuery($this->query);
}
}
In dit geval zijn er een aantal opties voor het afhandelen van de gegenereerde query voordat Foo::runQuery() wordt aangeroepen.
Natuurlijk is er altijd de mogelijkheid dat u de query niet synchroon of in de constructor wilt maken en uitvoeren.
Concluderend ben ik persoonlijk van mening dat voor methoden die interageren met services die onafhankelijk zijn van het object zelf, zoals Sql of misschien gefocuste DOMDocument of soortgelijke objectinteracties, het het beste is om statische methoden te gebruiken waar ze beide relevant zijn en uiteindelijk niet je neus afsnijden ondanks je gezicht (onnodig ingewikkeld etc). Dit moet natuurlijk allemaal per klasse worden bekeken.