Vilket är det bästa sättet att minska antalet frågor när Class DAO har metoder som använder samma resultat?

Detta svar är beroende av den aktuella frågestrukturen, där det inte finns några villkor

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();
    }
}

Tankeprocessen bakom detta är att eftersom resultaten alltid kommer att vara desamma (ignorera, uppdatera, infoga, ta bort för tillfället) finns det inget krav på att behålla en kopia av resultaten i varje objekt.

Som du påpekade kommer tabelluppdateringar att slå den lagrade resultatuppsättningen ur synk med objektet; det är här jag skulle vilja backa lite och säga att om resultatuppsättningen för ett givet objekt bara måste vara uppdaterad vid tidpunkten för skapandet, använd normala objektmedlemmar.

Också värt att överväga både oberoende och i samband med föregående kommentar är om frågan kommer att ändras eller inte och om den gör det kräver det att objektmedlemmar genereras. Om frågan inte ändras så finns det inget att oroa sig för - förutom föregående punkt. Om det ändras täcks dina alternativ mer eller mindre i följande exempel.

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));
    }
}

I det här exemplet använder du fortfarande en statisk metod för att generera frågan men du skickar icke-statiska medlemmar för processen/ Vid det här laget (se kommentar om objekt som är uppdaterade vid tidpunkten för skapandet) kan du antingen lagra resultat inom den statiska medlemmen eller skicka tillbaka dem till funktionen __construct() och lagra i objektinstansen.

Sedan finns det potentialen att frågan du använder är lite mer involverad än att bara begära vissa fält så att skapa en flerdimensionell array för att skicka till den statiska funktionen skulle vara mer krångel än det är värt. I så fall kan du dela upp buildAndRunQuery() i buildQuery() - instansmetoden och runQuery() statisk metod som t.ex.

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);
    }
}

I det här fallet finns det ett par alternativ för att hantera den genererade frågan innan du anropar Foo::runQuery().

Naturligtvis finns det alltid möjligheten att du inte vill skapa och köra frågan på ett synkront sätt eller faktiskt i konstruktorn.

Sammanfattningsvis anser jag personligen att för metoder som interagerar med tjänster oberoende av själva objektet, såsom SQL eller kanske fokuserade DOMDocument, eller liknande, objektinteraktioner är det bäst att använda statiska metoder där de både är relevanta och inte i slutändan skär av näsan för att trots ditt ansikte (onödigt komplext etc). Naturligtvis måste allt detta beaktas per klass.