Utilizzare una connessione al database DSN è una cattiva pratica?

Question

Utilizzare una connessione al database DSN è una cattiva pratica?

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

3

Durante tutta la mia vita professionale che ho programmato in ambiente Windows, ho consigliato ai miei amici e colleghi di non utilizzare una connessione DSN nelle loro applicazioni, sulla base delle mie conclusioni personali, ma non ho visto alcuna prova di loro.

So che l'utilizzo di una connessione DSN tramite l'origine dati ODBC implica che questa connessione utilizzerà un driver ODBC. Conosco da alcuni documenti che ODBC è una API agnostica, OS-agnostica per connettersi ai database, tutto ciò che porta questo livello di flessibilità comporta alcuni downpoint (potrebbe essere possibile che alcune funzionalità specifiche non possano essere usate con ODBC) o potrebbe essere che le prestazioni potrebbero essere inferiori rispetto all'utilizzo di un'API più diretta (OLEDB o altro).

So che l'utilizzo di una connessione senza DSN presenta alcuni problemi di per sé, come la memorizzazione sicura delle informazioni di accesso al server / file del database (può essere risolto con una sorta di crittografia sui dati) o modifiche inattese nel nome di provider utilizzato nei driver di connessione (caso specifico dei vecchi driver informix).

È corretto, o sono qualcosa di incomprensibile?

language-agnostic programming-practices database windows

posta Rafael 16.05.2012 - 17:47

fonte

2 risposte

1

Come diceva KenK, un assoluto "buono" o "cattivo" è una chiamata difficile. Un potenziale negativo dell'utilizzo di una connessione DSN è che se è necessario apportare modifiche, può essere difficile aggiornare tutti i client. Un altro è se gli sviluppatori devono cambiare server per i test, può essere difficile farlo, in particolare negli ambienti aziendali che bloccano sempre più l'accesso degli sviluppatori ai comandi del pannello di controllo. Potrebbe essere più facile e migliore utilizzare un file di configurazione, a cui gli sviluppatori potrebbero essere concessi esplicitamente il permesso di cambiare localmente nelle proprie caselle di sviluppo e potrebbe essere aggiornato come parte dello script di accesso alla rete per gli utenti regolari se è necessario apportare modifiche. Ci sono anche altre opzioni. Ma in realtà dipende dalle tue esigenze specifiche.

risposta data 23.05.2012 - 20:23

fonte

Leggi altre domande sui tag language-agnostic programming-practices database windows

Che cosa suggerisci per le app multipiattaforma, incluso il web TDD aggiungendo proprietà semplici

score 4 · Accepted Answer

Andrò su un arto e dirò di no non è "cattiva pratica". È uno strumento destinato a implementazioni flessibili. Potrei non usarlo mai come preferirei usare l'API nativa per le connessioni al database, ma ha chiaramente uno scopo. Se si sta scrivendo client-ware per connettersi a database arbitrari in diversi ambienti di lavoro, una soluzione DSN potrebbe ragionevolmente risparmiare un sacco di lavoro. Scriveresti le tue librerie di connessione per usare DSN via odbc e riuscire a parlare con qualsiasi sistema di dati che usano.

Per cercare di capirlo meglio, magari ponendo la domanda:

È "buona pratica" usare l'API db-native per accoppiare l'app client con il suo backend, legando quindi l'applicazione a uno specifico sistema di storage?

Dovresti riscrivere il client nel caso volessi cambiare il back-end. l'approccio DSN è backend agnostico quindi potenzialmente migliore.

D'altro canto, avere sistemi omogenei è di per sé un vantaggio quando si tenta di assumere qualcuno per entrare in una correzione / aggiornamento / aggiornamento del sistema. Invece di assumere un appaltatore "generico DBS-using", ti ritrovi un esperto Oracle, Access, MSSQL o Mysql e lavorerebbero nella loro area di competenza.

Sono sempre riluttante a chiamare a titolo definitivo "cattivo". Esiste quindi deve aver avuto una buona ragione per venire in esistenza. Veramente (e intendo al 100%) le cose "cattive" tendono a non essere largamente adottate. Forse diventano cattivi nel tempo (scrollando le spalle).