Rompe SRP per avere preoccupazioni sulla gestione dei dati e sulla mappatura degli oggetti all'interno di una singola classe, come parte del pattern DataMapper?

Non ho mai visto il punto di una classe che interroga solo il database e restituisce un array (o DataSet o DataTable per quelli in .NET). La mappatura delle colonne in un database su proprietà o campi su un oggetto appartiene alla sua classe, non al costruttore. L'intero punto di un mapper dei dati è quello di disaccoppiare lo schema del database dal modello a oggetti. Passando $data come argomento costruttore a MyProduct hai incorporato lo schema del database nel tuo modello a oggetti.

Un modello più chiaro e diretto è quello di creare una classe di repository che si occupa esclusivamente del modello di oggetto. Avrebbe un oggetto mapper dei dati che associa le colonne ai campi nel tuo modello a oggetti.

Innanzitutto, il tuo mapper:

class DataMapper {
    public function toMyProduct($data) {
        $product = new MyProduct();

        foreach ($data as $key => $value) {
            // Simple property injection:
            $product->$key = $value;

            // Or setter injection
            $setter = 'set' . ucfirst($key);
            $product->$setter($value);
        }

        return $product;
    }
}

Quindi la tua classe repository, che prenderebbe il mapper come argomento costruttore:

class MyProductRepository {
    private $mapper;

    public function __construct(DataMapper $mapper) {
        $this->mapper = $mapper;
    }

    public function find($id) {
        $sql = "...";
        // build parameterized query
        $result = db_query($sql);
        $data = db_fetch_array($result);//array('name'=>"ABC-1234");

        return $this->mapper->toMyProduct($data);
    }

    public function update(MyProduct $product) {
        // build parameterized query for UPDATE statement
    }
}

La vera pulizia di questo approccio diventa evidente quando inizi a utilizzare queste classi insieme:

$mapper = new DataMapper();
$products = new MyProductRepository($mapper);
$product = $products->find(10);
echo $product->getName();

Puoi fare un ulteriore passo avanti e implementare il modello di unità di lavoro usando un oggetto di contesto del database, che avvolge tutto le classi di repository per ogni tabella nel database:

class DbContext {
    public __construct() {
        $this->mapper = new DataMapper();
        $this->products = new MyProductRepository($this->mapper);
    }

    public $products;

    public function commit() {
        // issue COMMIT command to the database
    }

    public function rollback() {
        // issue ROLLBACK command to the database
    }
}

Ora il tuo codice diventa ancora più pulito, con l'ulteriore vantaggio della gestione delle transazioni:

$db = new DbContext();

try {
    $product = $db->products->find(10);
    // do stuff with $product

    $db->products->update($product);
    $db->commit();
} catch (Exception $ex) {
    $db->rollback();

    throw $ex;
}

Se veramente hai bisogno di un metodo che restituisce l'array raw dal database, questo diventa solo un altro metodo sulla tua classe repository:

class MyProductRepository {
    private $mapper;

    public __construct(DataMapper $mapper) {
        $this->mapper = mapper;
    }

    public function find($id) {
        $data = $this->findData($id);

        return $this->mapper->toMyProduct($data);
    }

    public function findData($id) {
        $sql = "...";
        // build parameterized query
        $result = db_query($sql);
        $data = db_fetch_array($result);//array('name'=>"ABC-1234");

        return $data;
    }

    public function update(MyProduct $product) {
        // build parameterized query for UPDATE statement
    }
}

Il codice di esempio n. 2 che hai fornito è preferibile, a mio parere.

Che cosa succede se domani vuoi avere CachedProductData, devi solo aggiornare la classe dei dati di prodotto, o piuttosto introdurre un altro layer.

Se hai entrambe le classi unite come nell'esempio 1, aggiorneresti entrambe le responsabilità.

Quindi, il Principio di Responsabilità Unica sarà rotto se scegli l'esempio # 1.