Modello di dominio anemico, Business Logic e DataMapper (PHP)

3

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.

    
posta sunwukung 09.03.2011 - 18:19
fonte

2 risposte

1

Col senno di poi, la mia domanda avrebbe dovuto essere "qual è la logica aziendale". La risposta che stavo cercando era questa:

link

Ho trovato anche questa divertente analogia: link

L'ho messo su cwiki per impedire l'up-repping

    
risposta data 10.03.2011 - 12:01
fonte
0

Idealmente, i tuoi oggetti di dominio dovrebbero essere ignoranti per la persistenza. L'utilizzo del modello di repository (che il tuo Mapper implementa insieme alla gestione delle traduzioni O / R) è il percorso preferito.

Osservando il tuo metodo alternativo, stai ricevendo un'istanza di un oggetto e poi dicendogli di caricarsi. È meglio che l'oggetto venga caricato a pieno carico (un'altra ragione per considerare l'ignoranza di persistenza).

    
risposta data 09.03.2011 - 18:46
fonte

Leggi altre domande sui tag