C'è qualche vantaggio nell'usare una classe PHP per gestire le query MySQL?

-2

So che diversi framework hanno questa funzionalità integrata in cui è possibile utilizzare i loro metodi speciali per creare query DB. So anche che questo è (parzialmente) per garantire che tutto sia gestito correttamente per evitare di rompere le cose. Quindi, ecco la domanda, se non si utilizza un framework, c'è un vantaggio sufficiente per usare una classe come quella piuttosto che digitare SQL a mano dove necessario? Considera il seguente codice.

/* What the method might look like and it's call */

$db->('little_bobby', array('foo' => 'bar', 'baz' => 1337));

public function insert($table, $values)
{
  $cols = [];
  $vals = [];
  foreach ($values as $column => $value) {
    $cols[] = $column;
    $vals[] = $value;
  }
  $columns = implode(',', $cols);
  $bind_labels = ':'.implode(',:', $cols);

  $query = "INSERT INTO {$table} ({$columns}) VALUES ({$bind_labels})";

  $stmt = $dbc->prepare($query); //$dbc is the connection object

  foreach ($values as $column => $value) {
    $stmt->bindValue(":$column", $value);
  }

  return $stmt->execute();
}
/* As opposed to what it would look like by hand */

  $query = 'INSERT INTO little_bobby (foo, baz) 
                   VALUES (:foo, :baz)';
  $stmt = $dbc->prepare($query); //$dbc is the connection object
  $stmt->bindValue(':foo', 'bar');
  $stmt->bindValue(':baz', 1337);

  $result = $stmt->execute();

Ignora qualsiasi errore sintattico a meno che non impedisca la comprensione di ciò che sto cercando di ottenere qui. Si noti che non sto chiedendo se si dovrebbe usare le classi per organizzare il codice, ma piuttosto se destinare una classe alla costruzione e all'esecuzione di query DB è meglio che scrivere una query a mano.

    
posta amflare 20.10.2016 - 00:45
fonte

1 risposta

3

Iniezioni SQL

Nel tuo primo esempio, apri una porta alle Iniezioni SQL. Questo può accadere in questo modo:

  1. Utilizzerai insert($table, $values) su tutto il codice base. Grande.

  2. Un altro sviluppatore avrebbe seguito il tuo esempio.

  3. Un giorno, dovrà inserire un valore in una tabella scelta dinamicamente (ad esempio attraverso una mappa di input dell'utente). Se stava scrivendo una query SQL diretta, avrebbe pensato due volte ai rischi e probabilmente avrebbe scelto un approccio diverso. Ma qui, sta usando un metodo di cui si fida e forse crede di essere affidabile. Dopo tutto, perché il metodo tuo non dovrebbe essere sanitizzato? Ancora più importante, è molto, molto facile usare un nome dinamico per una tabella.

  4. In seguito, qualcuno noterà che l'input dell'utente è correlato al valore effettivo della variabile passata come primo parametro al metodo insert . Quindi, perché non assegnare il valore direttamente dall'input invece di utilizzare una mappa? E ora, un hacker può fare tutto ciò che vuole con il tuo database.

Flessibilità

Nel tuo primo esempio, puoi INSERT INTO . Niente di più. No ON DUPLICATE KEY UPDATE . Nessuna partizione. In realtà, non puoi nemmeno fare DEFAULT per i valori.

Nel tuo secondo esempio, l'immaginazione è il tuo unico limite. La query può essere modificata con facilità e la modifica è limitata a una o poche righe di codice.

leggibilità

Nel tuo primo esempio, devo percorrere tredici righe di codice solo per capire un inserimento di base. Perché tutta questa complessità? Quando inizierai a implementare DEFAULT s e le partizioni e tutte le altre cose, finirà con centinaia e centinaia di linee.

Nel tuo secondo esempio, il codice è proprio lì. Sono poche le affermazioni semplici che ho bisogno di leggere.

Maintainability

Prima o poi, finirai con domande che richiedono troppo tempo. Li identificherai e dovrai ottimizzare il database o le query.

Se hai le tue query direttamente nel codice, sarai in grado di semplicemente grep di loro la maggior parte del tempo (specialmente dal momento che SQL Profiler gestisce le query parametrizzate, quella per SQL Server non conosce gli altri ).

Se disponi di un ORM, è probabile che disponga di un proprio meccanismo di registrazione, che elencherà la query problematica e mostrerà la traccia dello stack corrispondente.

Se hai uno strato di astrazione come quello nella tua domanda, le cose potrebbero diventare disordinate.

Conclusione

Se non vuoi scrivere query SQL a mano, usa un ORM. Se si desidera scrivere query SQL a mano, ma non si desidera digitare codice ripetitivo, utilizzare un oggetto mapper. Non reinventare la ruota e non aggiungere complessità non necessaria .

    
risposta data 20.10.2016 - 01:59
fonte

Leggi altre domande sui tag