Beste practice: ORM (in PHP, ma in generale): Salva le modifiche al database direttamente o su richiesta?

3

Immagina un sistema ORM, indipendente dalla lingua, ma assumiamo PHP. I dati sono incapsulati in oggetti PHP e memorizzati e caricati dal database.

Consentiteci di avere un oggetto teorico "Persona" con più indirizzi (così mappato a 2 tabelle nel database), che può essere aggiunto da una funzione.

NON prendere in considerazione il modo in cui l'accesso agli elementi dei dati è fatto, non importa.

Alcuni esempi di codice:

$person = new Person();

$person->firstname = 'John';
$person->lastname  = 'Doe';
// ...

// THIS IS IMPORTANT!
$person->save();

$person->addAddress([
    'street' => '123, Foo Street',
    'city'   => 'New York',
    // ...
]);

$person->addAddress([
    'street' => '456, Bla Street',
    'city'   => 'Washington',
    // ...
]);

Cosa ti aspetti da come (quando!) gli indirizzi vengono salvati?

Opzione 1: vengono immediatamente salvati dopo la chiamata a addAddress ()

Opzione 2: la chiamata a addAddress () la inserisce solo nell'oggetto interno e viene salvata solo dopo una chiamata esplosa a Person :: save ().

Opzione 3: eventuali ulteriori idee sono ben accette.

Voglio sapere quale maggior parte delle persone preferirebbe, il che è più intuitivo, se ci sono pro / contro per / contro le diverse opzioni. Forse un argomento letale?

Inoltre, suppongo che l'opzione 2 sia più difficile da codificare (lo so, l'utilizzo di qualche framework può gestirlo, ma suppongo che la mappatura del database-oggetto sia molto più complicata, quindi deve essere fatto a mano), perché ha bisogno di tracciamento interno di nuove voci, voci rimosse, voci modificate ecc.

L'opzione 1 è più facile da codificare, ma non so se gli utenti (anche se sono solo nella nostra azienda) lo fraintenderanno.

    
posta Schubi Duah 22.03.2017 - 11:17
fonte

2 risposte

1

Non mischiare mai la gestione dei dati con la gestione delle transazioni. In questo modo i tuoi metodi di gestione dei dati non sono riutilizzabili. Consenti al chiamante di eseguire il commit del database, questo consentirà al chiamante del metodo di modifica dei dati di comporre più chiamate da eseguire in una singola transazione e, in caso di problemi, di eseguire il rollback di tutte le transazioni.

Quindi suggerirei di fare l'Opzione 2.

Gli unici altri miglioramenti che suggerirei sono piuttosto che

$person->save();

ha invece una sessione di database esplicita:

// either: $session->add($person);
// or: $person = new Person($session);
// alternatively: $person = $session.create(Person);

$session->save();

Le sessioni esplicite possono sembrare inizialmente ingombranti, ma molte altre cose sono più facili da apprezzare in seguito. I test diventano più semplici, il riutilizzo dei metodi diventa più semplice, più database diventano possibili, ecc.

    
risposta data 22.03.2017 - 14:35
fonte
0

[Opzione 3]

Forse dovresti dare un'occhiata ai pattern di Entità e Repository, potrebbe aiutarti a capirlo.  Ad esempio:

Hai la tua entità Person

<?php
namespace PersonEntity\subnamespace;
class PersonEntity {
    public $firstname;
    public $lastname;

static function register(){}

}
?>

Crea un'interfaccia per la tua entità

<?php
interface PersonRepository {
   public function save(Person $person);
}
?>

Quindi devi solo creare una classe che implementa la tua interfaccia

<?php    
class ArrayPersonRepository implements PersonRepository {
      public function save(Person $person){}
}
?>

Quindi puoi interagire con il tuo repository, in questo modo:

$person = PersonEntity::register($firstname, $lastname)
$personRepository->save($person)

I vantaggi del codice che utilizzano questi pattern sono:

  • Keep it SOLID.
  • Cambia il tuo database in base alle tue preferenze.
  • Il codice è facilmente testabile.
risposta data 22.03.2017 - 14:15
fonte

Leggi altre domande sui tag