Devo controllare l'integrità nel mio codice applicazione o rinviare al database? [duplicare]

Question

Devo controllare l'integrità nel mio codice applicazione o rinviare al database? [duplicare]

#1 da (4 voti)
#2 da (1 voti)

3

Al lavoro abbiamo un sacco di codice come questo (pseudocodice):

response form_submit(string username, string password) {
  if (  username == ""
     || username.contains(invalid_chars)
     || password.length < 5 
     || ...
     ) {
    return "errors: blah blah";
  } else {
    try {
      db("insert into users(username, password) values (?, ?)", username, password);
      return "success";
    }
    catch (DBException e) {
      return "errors: blah blah";
    }
  }
}

Alcuni di questi sono applicati come vincoli sul DB, altri no. Ha più senso per me imporre tutto come vincoli di DB e basta fare

response form_submit(string username, string password) {
  try {
    db("insert into users(username, password) values (?, ?)", username, password);
    return "success";
  }
  catch (DBException e) {
    return "errors: blah blah";
  }
}

La mia opinione è ovvia qui, ma qual è la tua: questo tipo di applicazione di prova di integrità dei dati a livello di applicazione non è buona?

database code-smell rules-and-constraints

posta jameshfisher 15.03.2013 - 21:39

fonte

2 risposte

Leggi altre domande sui tag database code-smell rules-and-constraints

2 domande su TDD Come posso ottenere git per clonare i file non tracciati

score 4 · Answer 1

A parte tutte le considerazioni sulle prestazioni e sulla ridondanza, a meno che le eccezioni del database .net siano più sofisticate che in ogni altra lingua con cui abbia mai lavorato, il semplice fatto di dover costruire un messaggio di errore leggibile dai non programmatori richiede necessariamente il primo metodo, a meno che non si preferiscano messaggi di errore che leggano qualcosa del tipo:

Error #0x4b13: Violated length constraint '>=5' for table 'Users', field 'password'.

Quello che finirai per fare è ricreare comunque il codice di convalida per produrre un messaggio di errore decente, e se hai intenzione di ricreare quel codice in ogni caso, puoi farlo anche prima di sostenere le spese di una chiamata al database .

score 1 · Answer 2

Nel database, non sarai in grado di convalidare la lunghezza della password (poiché è hash e non in chiaro, giusto? RIGHT ?).

Il test per i caratteri non validi nel nome utente deve essere eseguito prima di scrivere la tua istruzione INSERT , altrimenti sei completamente aperto a un attacco di SQL injection. Quale sarebbe molto meno probabile se invece si utilizzasse una query parametrizzata, ma è un rischio che si deve sempre considerare.

La ridondanza degli assegni è preziosa, come sottolineato da Ratchet.