Come inserire un livello di database in PHP

Question

Come inserire un livello di database in PHP

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Gestisco e aggiungo funzionalità su base freelance a un sito Web scritto in PHP. L'applicazione è stata avviata in PHP4 da un programmatore junior nel 2006 e presenta alcuni modi di fare le cose molto insicuri e non mantenibili, che sto cercando di correggere col passare del tempo. Se il cliente è d'accordo, una delle prime cose che vorrei fare è aggiungere un opportuno livello di database di qualche tipo.

L'accesso al database corrente è simile a questo:

if (!function_exists('my_query')) {
function my_query($query) {

    if ($query=='disabled') return false;

    global $last_insert_id,$dbconn,$dbase;


    $result=mysql_query($query,$dbconn) or die('ERROR: '.mysql_error($dbconn).'<br />'.$query);
    $last_insert_id=mysql_insert_id($dbconn);
    return $result;
}
}

C'è anche una funzione per rendere array dai dati restituiti.

if (!function_exists('spawnarray')) {
function spawnarray($result)
{
    $i = 0;
    if ($result != "") {
        if (mysql_num_rows($result) > 0) {
            while($result_obj[$i] = mysql_fetch_object($result)) {
                $sp_result[$i]=$result_obj[$i];
                $i++;
            }
            return $sp_result;
        }
    }
}
}

Queste due funzioni sono fondamentalmente il livello del database e le query SQL sono costruite al volo per tutte le posizioni.

Quindi la mia domanda è: come posso iniziare a introdurre l'astrazione del database nel mix? Mi piacerebbe passare a PDO per motivi di sicurezza e facilità di utilizzo, ma forse c'è un modo migliore per andare?

Ho già spostato il progetto in Composer per alcune delle sue dipendenze (alcuni sono progetti morti, che è un altro problema) quindi forse un ORM come Doctrine sarebbe la strada da percorrere? Ciò potrebbe significare spostare il sito web in OOP in una volta sola: una prospettiva scoraggiante e un sicuro no-go dal cliente.

database architecture php legacy

posta Tom Macdonald 03.09.2013 - 18:19

fonte

3 risposte

Leggi altre domande sui tag database architecture php legacy

Iniezione di dipendenza: dove archiviare le dipendenze utilizzate da un solo metodo? Design per oggetto con attributi opzionali e modificabili?

score 1 · Answer 1

Sembra che tu sia stato fortunato nel fatto che lo sviluppatore originale ha inserito una funzione 'wrapper' per gestire le query mysql_ *. Questo è molto meglio che avere 15.000 chiamate a mysql_query () diffuse attraverso il codice. Modificherei quelle funzioni ('my_query', 'spawnarray') per usare PDO come primo passo. Quindi, quando sei completamente fuori da mysql_ *, inizia a passare tutto a PDO se ne vale la pena (ad esempio, in base all'importanza / durata prevista dell'app in questione).

score 0 · Answer 2

Suggerirei di cercare di disaccoppiare il livello dati dalla logica di business della tua applicazione attraverso un modello come DAO .

Una volta che il livello di persistenza è correttamente disaccoppiato (e verificabile), puoi scegliere l'implementazione appropriata per le tue esigenze specifiche. Finché il livello dati è astratto, quella scelta può essere rimandata e puoi sempre sostituirla con un'implementazione più appropriata se le tue esigenze cambiano.

score 0 · Answer 3

Puoi anche usare Zend \ Db di Zend Framework, come vuoi tu. Non è necessario avere una revisione completa per implementarlo, è possibile iniziare a utilizzarlo solo per il nuovo codice. Quando il client approva, puoi iniziare a convertire il vecchio codice per usare anche Zend \ Db. In questo modo non stai aggiungendo un altro pezzo di codice da mantenere, basta usare il componente del ripiano.

Il vantaggio non è solo la sostituzione del vecchio livello del database, ma sarà anche possibile "sollevare" l'implementazione per utilizzare concetti di livello superiore come il Table Gateway e il Row Gateway, entrambi forniti in Zend \ Db.

Lo stesso vale per Doctrine, puoi usarlo dove vuoi, anche se è più pesante di Zend \ Db. Dipende anche dai problemi che vuoi risolvere, ad es. hai bisogno di Domain Model.