Ta odpowiedź zależy od aktualnej struktury zapytania, w której nie ma warunków
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();
}
}
Proces myślowy kryjący się za tym polega na tym, że ponieważ wyniki będą zawsze takie same (na razie zignoruj, zaktualizuj, wstaw, usuń), nie ma wymogu przechowywania kopii wyników w każdym obiekcie.
Jak wspomniałeś, aktualizacje tabeli spowodują, że przechowywany zestaw wyników nie będzie zsynchronizowany z obiektem; w tym miejscu chciałbym się nieco cofnąć i powiedzieć, że jeśli zestaw wyników dla danego obiektu musi być tylko aktualny w momencie tworzenia, użyj normalnych elementów obiektu.
Warto również rozważyć, zarówno niezależnie, jak i w połączeniu z poprzednim komentarzem, czy zapytanie ulegnie zmianie, a jeśli tak, to wymaga wygenerowania elementów obiektów. Jeśli zapytanie się nie zmieni, nie ma się czym martwić - z wyjątkiem poprzedniego punktu. Jeśli to się zmieni, twoje opcje są mniej więcej opisane w poniższych przykładach.
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));
}
}
W tym przykładzie nadal używasz statycznej metody do generowania zapytania, ale przekazujesz niestatyczne składowe dla procesu/ W tym momencie (patrz komentarz na temat obiektów, które były aktualne w momencie tworzenia) możesz albo przechowywać wyniki wewnątrz statycznego elementu członkowskiego lub przekaż je z powrotem do funkcji __construct() i zapisz w instancji obiektu.
Następnie istnieje możliwość, że zapytanie, którego używasz, jest nieco bardziej skomplikowane niż zwykłe żądanie pewnych pól, tak że utworzenie wielowymiarowej tablicy, która ma zostać przekazana do funkcji statycznej, byłoby bardziej kłopotliwe niż jest to warte. W takim przypadku możesz podzielić buildAndRunQuery() na buildQuery() - metodę instancji i metodę statyczną runQuery(), taką jak.
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);
}
}
W tym przypadku istnieje kilka opcji obsługi wygenerowanego zapytania przed wywołaniem Foo::runQuery().
Oczywiście zawsze istnieje możliwość, że nie chcesz tworzyć i uruchamiać zapytania w sposób synchroniczny lub rzeczywiście w konstruktorze.
Podsumowując, osobiście uważam, że w przypadku metod, które wchodzą w interakcje z usługami niezależnymi od samego obiektu, takimi jak Sql lub być może skoncentrowany DOMDocument lub podobne interakcje z obiektami, najlepiej jest używać metod statycznych, gdy są one zarówno istotne, jak i na złość (niepotrzebnie skomplikowaną itp.). Oczywiście wszystko to należy rozważyć dla każdej klasy.
