dovrei inserire le connessioni del database in una libreria di classi?

Naviga le tue risposte
2

Questa potrebbe essere una domanda stupida, ma non ho mai creato una libreria di classi prima

Il motivo per cui non voglio collegarmi a un database attraverso la libreria di classi è la gestione degli errori .. dovrei semplicemente lasciare gli errori per tornare a qualunque codice stia usando la libreria di classi? dovrei gestirlo lì? o dovrei semplicemente lasciarlo completamente e togliere l'intero oggetto del database dalla libreria, creando separatamente / copiando e incollando ogni volta che voglio usarlo.

Questo è un piccolo progetto con solo 12 classi, tutte sotto le 200 linee e verrà utilizzato solo nelle applicazioni aziendali interne. Probabilmente sarò l'unico a utilizzarlo per svilupparlo, a meno che non me ne vada e qualcuno debba apportare modifiche alle applicazioni.

È c # se questo fa la differenza anche minima?

    
posta Alex 25.01.2013 - 15:00
fonte

2 risposte

9

No, non dovresti.

Devi passare le stringhe di connessione come dipendenza oppure utilizzare ConfigurationManager per prelevarle dalla configurazione dell'applicazione.

L'hard coding significa che non puoi cambiarli senza ricompilare le librerie.

The reason I don't want to be connecting to a database through the class library is error handling

Logica falsa lì. Dovresti gestire i problemi del database in quel livello di accesso ai dati (che può essere in una libreria di classi) - altri problemi logici e di business dovrebbero essere gestiti nel livello della logica aziendale (che può anche essere la sua libreria di classi).

Eccezioni non gestite.

    
risposta data 25.01.2013 - 15:09
fonte
1

Normalmente si mette tutto ciò che riguarda l'accesso ai dati in un livello di accesso ai dati (DAL) che sarebbe un file DLL separato. Creare questa libreria di classi è abbastanza semplice. Ricordati solo di aggiungere un riferimento al tuo progetto appena creato nel tuo progetto principale.

Se si gestiscono o meno eccezioni nel DAL o si lascia che il livello della logica aziendale si occupi di esso è più una questione di gusti. Personalmente preferisco trattare con i codici di ritorno che indicano il successo o il fallimento piuttosto che circondare tutte le chiamate al DAL con try / catch.

Mantenere l'accesso ai dati in una diversa libreria di classi renderà il tuo codice più gestibile, anche se decidi di scalare il progetto. In un prodotto distribuito, gli aggiornamenti della logica del DAL possono essere semplici come scambiare un file DLL anziché aggiornare l'intero programma.

    
risposta data 25.01.2013 - 15:14
fonte

Leggi altre domande sui tag

Le condizioni di post di una routine sono un sottoinsieme di precondizioni? Cosa inserire in una documentazione di stored procedure?