Hvad er den bedste måde at reducere antallet af forespørgsler på, når Class DAO har metoder, der bruger det samme resultat?

Dette svar er afhængigt af den aktuelle forespørgselsstruktur, hvor der ikke er nogen betingelser

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 bag dette er, at da resultaterne altid vil være de samme (ignorer, opdater, indsæt, slet indtil videre), er der ikke noget krav om at opbevare en kopi af resultaterne i hvert objekt.

Som du påpegede, vil tabelopdateringer slå det gemte resultatsæt ud af synkronisering med objektet; Det er her, jeg gerne vil gå lidt tilbage og sige, at hvis resultatsættet for et givet objekt kun skal være opdateret på oprettelsestidspunktet, så brug normale objektmedlemmer.

Også værd at overveje både uafhængigt og i forbindelse med den tidligere kommentar er, om forespørgslen vil ændre sig eller ej, og hvis den gør det, kræver det, at der genereres objektmedlemmer. Hvis forespørgslen ikke ændrer sig, er der intet at bekymre sig om - undtagen det foregående punkt. Hvis det ændrer sig, er dine muligheder mere eller mindre dækket i de følgende eksempler.

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 dette eksempel bruger du stadig en statisk metode til at generere forespørgslen, men du sender ikke-statiske medlemmer til processen/ På dette tidspunkt (se kommentar om objekter, der er opdateret på oprettelsestidspunktet) kan du enten gemme resultater inden for det statiske medlem, eller send dem tilbage til funktionen __construct() og gem i objektforekomsten.

Så er der potentialet for, at den forespørgsel, du bruger, er en smule mere involveret end blot at anmode om bestemte felter, så det ville være mere besværligt, end det er værd at oprette et multidimensionelt array til at overføre til den statiske funktion. I så fald kan du opdele buildAndRunQuery() i buildQuery() - instansmetoden og runQuery() statisk metode, såsom.

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 dette tilfælde er der et par muligheder for at håndtere den genererede forespørgsel, før du kalder Foo::runQuery().

Selvfølgelig er der altid muligheden for, at du ikke ønsker at oprette og køre forespørgslen på en synkron måde eller faktisk i konstruktøren.

Afslutningsvis føler jeg personligt, at for metoder, der interagerer med tjenester, der er uafhængige af selve objektet, såsom SQL eller måske fokuserede DOMDocument eller lignende, objektinteraktioner, er det bedst at bruge statiske metoder, hvor de både er relevante og ikke i sidste ende skærer din næse af for at trods dit ansigt (unødigt komplekst osv.). Naturligvis skal alt dette overvejes pr. klasse.