Quando e quanto dovremmo convalidare l'input quando si lavora con lo storage AP (C)?

4

Qui, consideriamo un'architettura server-client. Supponiamo di mantenere i dettagli flessibili, ma esiste più di un livello di server che supporta il nostro servizio ipotetico. La domanda generale è "Quando e quanto convalido i dati del cliente?" .

Da altre domande e risposte che ho letto, la risposta può essere riassunta come una delle seguenti strategie (o una loro combinazione).

  1. Convalida tutti i dati non appena arrivano dal client. Altri server si fidano l'un l'altro.
  2. Convalida tutti i dati su ogni server nel sistema. (questo non è molto favorito)
  3. Convalida tutti i dati rigorosamente quando raggiunge il database e, facoltativamente, altrove come richiesto dall'applicazione.
  4. A tutti i livelli, convalidare esattamente tutti i dati necessari a quel particolare server per svolgere il proprio lavoro.

Il numero 3 sembra particolarmente popolare .

Nelle risposte che ho visto, tuttavia, sembra esserci un'assunzione implicita dell'archiviazione dei dati centralizzata RDBMS classica ("OldSql"). Questi sono i MySQL e Postgres del mondo. Prendendo spunto dal teorema CAP , chiamiamo questi database CP , poiché tendono a fornire strumenti per coerenza a scapito di alcune classi di disponibilità: in genere, solo un master delegato può scrivere su una particolare partizione.

Le alternative recenti al classico RDBMS (in particolare Voldemort, Riak e Cassandra, che sono modellate sul sistema di storage Dynamo) sono meglio classificate come database AP . Questi strumenti consentono di comparire incoerenze naturali al momento del recupero dei dati (ad esempio più valori di dati con clock vettoriali) in cambio della disponibilità "sempre scrivibile". Dato che questi archivi di dati hanno piuttosto proprietà uniche , pongo la domanda:

La storia di convalida dei dati del client cambia quando utilizziamo i datastore AP? Quanti dei miei dati cliente dovrei convalidare prima e dopo l'inserimento in un database AP?

    
posta Andres Jaan Tack 13.10.2011 - 19:43
fonte

2 risposte

1

In qualsiasi sistema (CP o AP) vorrei andare per l'opzione 1.

Ci sono molti vantaggi nella convalida il prima possibile.

  • Hai l'intera transazione, ne sai tutto e chi l'ha avviata. Puoi fornire messaggi di errore significativi.
  • Puoi controllare molto di più.
  • Dovresti essere "di sola lettura" fino a quando l'intera richiesta non viene convalidata. Nessun arretramento complesso di cui preoccuparsi!
risposta data 18.10.2011 - 12:43
fonte
1

Questo problema ruota attorno alla capacità di fidarsi di un livello chiamante. Ogni comunicazione intra livello può essere vista come un sistema client-server. Ad un certo punto finirai con lo strato inferiore per fare una decifrazione mentre i dati in arrivo sono validi. Quindi, il paradigma è valido, non fidarti di nulla che il cliente ti dice!

La convalida eseguita varia in base al livello dell'applicazione, in particolare per responsabilità di livello. Se parli di un livello di persistenza, dovrebbe almeno controllare se è in grado di archiviare e recuperare correttamente i dati trasmessi dal cliente. Se viene trovato qualcosa di non valido, solo il chiamante deve essere informato. Il chiamante stesso è quindi responsabile di ulteriori notifiche. Ciò significa anche che non controlli le regole di business perché in sostanza non è la responsabilità del livello di persistenza.

    
risposta data 20.10.2011 - 19:18
fonte

Leggi altre domande sui tag