Mantenere un modello MVC liberamente accoppiato dal DB?

Un modo è quello di progettare i modelli prima di progettare il database. Quando si progettano i modelli, l'obiettivo è catturare la logica e i significati aziendali all'interno del dominio del problema. Questo dovrebbe essere catturato in un modo che ha senso per il business, tra cui più di semplici entità e campi di dati. Alcuni elementi di dati sono interpretati dagli altri, alcuni sono dipendenti da altri, ecc. Inoltre, devi aggiungere a questo modello qualsiasi logica di base che ti serve, come ad esempio il modo in cui un oggetto risponde internamente quando un determinato elemento è impostato su un determinato valore. p>

È molto probabile che ti ritroverai con qualcosa che è 90 +% identico a come finisci per mantenere i dati. Va bene. Può essere completamente identico senza essere accoppiato.

Nota anche che modellare il dominio in una nebbia di vera ignoranza di persistenza è un po 'un sacro graal per la progettazione del software. Se puoi farlo, fantastico. Ma se il dominio del problema è del tutto significativo e ha una certa complessità, allora è comunque una buona idea fare un passo indietro dalla modellazione del dominio di volta in volta per fare un controllo sulla persistenza dei dati per assicurarsi di non aver dipinto te stesso in un angolo.

Ricorda solo i ruoli reali dei vari componenti e tieni separati quei ruoli quando li disegni. Per qualsiasi decisione sul design, chiediti se qualcuno di questi ruoli è stato violato:

1. Database - Memorizza i dati, conserva l'integrità dei dati, conserva i dati a riposo.
2. Modelli: contengono la logica aziendale, modellano il dominio del problema, mantengono i dati in movimento, rispondono agli eventi a livello aziendale, ecc.
3. Visualizzazioni - Presenta i dati agli utenti, esegui la logica lato utente (convalida di base prima che la validazione vera venga eseguita nei modelli, ecc.).
4. Controller: risponde agli eventi utente, passa il controllo ai modelli, inoltra le richieste e restituisce le risposte.

Vuoi avere due cose.

1. I tuoi modelli (accessors al DBAL e facendo la maggior parte della logica dell'app).

2. I tuoi "Modelli di dominio", ovvero entità di dati, rappresentano le entità del tuo sistema come utenti, post, prodotti ecc.

   class PPI_Model_User {
   
       protected $_conn = null;
   
       function __construct(array $options = array()) {
           if(isset($options['dsnData'])) {
               $this->_conn = new PPI_DataSource_PDO($options['dsnData']);
           }
       }
   
       function getAll() {
           $rows = $this->_connect->query("SELECT .....")->fetchAll();
           $users = array();
           foreach($rows as $row) {
               $users[] = new PPI_Entity_User($row);
           }
           return $users;
       }
   
   }
   

Codice di utilizzo

    $model = new PPI_Model_User(array('dsnData' => $dsnData));
    $users = $model->getAll();
    foreach($users as $user) {
        echo $user->getFirstName();
    }

Ecco qua, è come crei modelli di dominio (Entità) e fai in modo che i modelli MVC eseguano la connettività DB e la manipolazione dei dati.

Se ti stai chiedendo quale PPI sia, google per "PPI Framework".

Buona fortuna con la tua ricerca.

Saluti, Paul Dragoonis.

Ricordate, MVC è sorto in smalltalk, che ha persistenza automatica per tutti gli oggetti. Quindi il modello MVC non prescrive alcuna soluzione per la separazione modello / persistenza.

La mia preferenza è di fornire un oggetto "Repository" che sappia come creare oggetti Model dal database e memorizzare gli oggetti Model nel database. Quindi il Modello non sa nulla della persistenza. Tuttavia, alcune azioni dell'utente dovranno attivare un salvataggio, quindi è probabile che il Controller conosca il Repository. Di solito utilizzo una qualche forma di Iniezione delle dipendenze per impedire che il Controller venga accoppiato al Repository.