Ho implementato uno strato ORM rudimentale basato su DataMapper (non voglio usare un ORM completo come Propel / Doctrine - per qualcosa al di là di semplici operazioni di recupero / salvataggio preferisco accedere al livello direttamente dei dati usando un SQL strato di astrazione).
Seguendo il pattern DataMapper, ho cercato di mantenere tutte le operazioni di persistenza nel Mapper, inclusa la posizione delle entità correlate.
Le mie Entità hanno accesso al loro Mapper, anche se cerco di non chiamare la logica del Mapper dall'interfaccia Entity (anche se questo sarebbe abbastanza semplice). Il risultato è:
// get a mapper and produce an entity
$ProductMapper = $di->get('product_mapper');
$Product = $ProductMapper->find('[email protected]','email');
// could easily be this
// $Product = $di->get('product');
// $Product->load('[email protected]','email');
//.. mutate some values.. save
$ProductMapper->save($Product)
// uses __get to trigger relation acquisition
$Manufacturer = $Product->manufacturer;
Ho letto alcuni articoli riguardanti il concetto di un modello di dominio anemico, ovvero un modello che non contiene alcuna "logica aziendale". Quando si dimostra il tipo di logica aziendale ideale per un modello di dominio, tuttavia, l'acquisizione di elementi di dati correlati è un esempio comune.
Quindi volevo porre questa domanda: La logica di persistenza è appropriata negli oggetti del modello di dominio? O meglio - quale logica entra nelle classi Entity una volta che la persistenza e la gestione delle relazioni vengono inserite nel mapper.