Perché inserire una semplice query in una stored procedure in un servizio Web?

4

Lavoro come programmatore junior e il programmatore senior sopra di me mi ha incaricato di seguire una certa politica non ufficiale per la costruzione di nuove query sui nostri progetti di sviluppo web. Generalmente, stiamo sviluppando un sito intranet per alcuni client e hanno sempre dei database. Vuole che io abbia una classe contenente un metodo per ogni query eseguita dal sito web. Questa classe chiama i metodi web in un servizio web, ospitato sullo stesso computer. Questi metodi Web utilizzano ADO per eseguire stored procedure che eseguono query semplici. A volte le query hanno bisogno di parametri e altre volte no. Quando dico semplici query, intendo semplice ... select * from table where column=@parameter

Mi sento come se ci fossero diversi passaggi in più qui, e spero che qualcuno possa spiegare perché potrebbe volere questo come la nostra procedura standard per l'utilizzo di database nelle app web. Dice che ogni passaggio aggiunge uno strato di sicurezza. Sono sinceramente interessato a come tutto questo fornisce sicurezza. È tutto ciò necessario? Perché o perché no?

    
posta Isaac Fife 13.08.2012 - 02:02
fonte

2 risposte

9

L'idea alla base di questo è probaby per mantenere un basso grado di accoppiamento. L'applicazione comunica solo con il servizio Web e il servizio Web comunica solo con le stored procedure. Non ci sono istruzioni SQL nel codice front-end, solo chiamate al servizio web; e non ci sono istruzioni SQL diverse dalle chiamate stored procedure nel servizio web. Ci sono diversi vantaggi a questo:

  • È più gestibile. Tutte le query SQL si trovano in un unico posto, quindi non devi mai andare a cercarle (e probabilmente trascurare una cruciale).
  • Ogni componente (servizio web, front-end, database) può essere scambiato singolarmente per test e debug.
  • Molti tipi di errori rimangono contenuti in un modulo, ad es. non ci può essere alcun errore di sintassi SQL nel front-end, perché non contiene affatto SQL.
  • Se a un certo punto è necessario migrare a versioni più recenti dei componenti della piattaforma, è possibile migrare ciascun componente singolarmente, attenuando i rischi. Ad esempio, è possibile scegliere di spostare il front-end in un .NET più recente, mentre il server di database esegue ancora la versione precedente.
  • È più scalabile. Se a un certo punto decidi di dividere il database e il front-end su server diversi, puoi semplicemente configurare il front-end per parlare con un altro host per il servizio web o configurare il servizio web per connettersi a un altro host di database, o anche entrambi (che creerebbe una struttura a tre livelli fisicamente separata). Inoltre, è possibile implementare la memorizzazione nella cache e il bilanciamento del carico a diversi livelli, incluso il servizio web intermedio. E se a un certo punto decidi che hai bisogno di dividere il tuo database, probabilmente puoi implementare la logica richiesta nel servizio web, senza compromettere il front-end.

E c'è la responsabilità: spostando le query effettive nel database, diventano parte del regno del DBA. Se hai un DBA decente, probabilmente è molto più bravo in SQL di te (specialmente quando si tratta di casi limite oscuri e business-critical che possono avere effetti drammatici sulle prestazioni) ed è una buona cosa averlo almeno da controllare SQL prima che entri in produzione.

    
risposta data 13.08.2012 - 08:08
fonte
9

Ne parlavo con un DBA qualche settimana fa. In sostanza, fornisce a loro un ulteriore livello di sicurezza contro tu che commetti un errore. Se non parametrizzi correttamente quella query, c'è la possibilità che qualcuno malintenzionato possa inserire SQL nel tuo database che può fare grave danno.

E qui è dove sorge il conflitto. Pensi di fare sempre il tuo lavoro correttamente, quindi non c'è bisogno di quel livello di sicurezza. E potresti avere ragione. Ma ho visto sviluppatori senior scrivere query ad-hoc che sono vulnerabili a SQL Injection, quindi posso capire un DBA che insiste su quella policy.

È il suo collo sulla linea (o almeno colui che riceverà una chiamata alle 4 del mattino) se commetti un errore che distrugge il database.

    
risposta data 13.08.2012 - 02:20
fonte