. Net Architettura del progetto e connessione DB

Il modo in cui strutturo normalmente le applicazioni consiste nel disporre di tutti gli accessi al database in una DLL (modulo per altre lingue). Tutti i metodi di accesso ai dati accettano una stringa di connessione come parametro (nel caso di EF è un po 'diverso ma viene comunque passato in base alla stringa di connessione in app.config o web.config dell'applicazione primaria).

In questo modo il DAL (Data Access Layer) conosce la struttura del database ma non conosce alcun dettaglio di connessione. Significa che è possibile scambiare la stringa di connessione in fase di esecuzione per connettersi a DEV, UAT o PROD. La struttura di base di un metodo DAL sarebbe simile a questa:

Public SomeType GetData(string connectionString)
{
    try
    {
        using (SqlConnection sqlConnection = new SqlConnection(connectionString))
        using (SqlCommand cmd = new SqlCommand("", sqlConnection))
        {
            sqlConnection.Open();

            cmd.CommantText = "SomeSqlHere";

            SomeType returnVal = //Code to get your data and map to your return type

            return returnVal;
        }
    }
    catch (Exception ex)
    {
        Log.Error("Caught error.", ex);

        throw;
    }
}

Gli interni sarebbero un po 'diversi per EF, ma nel complesso l'uso di Dependency Injection consente di salvare stringhe di connessione hardcode in vari punti.

Per quanto riguarda l'iniezione della stringa di connessione, normalmente ho una classe Configuration che legge e talvolta memorizza nella cache i valori di configurazione. Questa configurazione ha assunto molte forme e si è evoluta in base alle esigenze dell'applicazione specifica su cui sto lavorando. La chiamata a un metodo dati sembrerebbe GetDate(Config.GetConnectionString()) . Quindi, solo una posizione nell'applicazione deve sapere qual è la stringa di connessione e in quale altro luogo viene passata.

Hai bisogno di Iniezione delle dipendenze - con l'IDbConnection iniettato nelle tue classi. Ecco alcuni vantaggi rapidi che mi vengono in mente:

1. Si specificano solo i parametri di connessione in un unico posto, quando viene registrato IDbConnection.
2. Hai la possibilità di sostituire IDbConnection con SqlConnection, SqlCeConnection e così via.
3. Hai un controllo migliore sulla transazione lungo la strada - dal momento che esiste una sola connessione. Se i metodi del modello gestiscono la connessione da soli, è necessario il coordinamento delle transazioni distribuite.

Ora, l'utilizzo di un framework DI può sembrare complesso e molto pericoloso, specialmente questa è la prima volta che si inizia a usarlo, ma il vantaggio del controllo delle transazioni da solo dovrebbe essere sufficiente per convincere te stesso.

Di solito le informazioni sulla connessione al database si trovano nel file .config per il progetto e il tuo database che accede alle classi lo leggerà in una variabile locale. Utilizzare .NET System.Configuration impostazioni per leggere le informazioni dal file .config usando delle belle librerie create da Microsoft.

A seconda di quanto centralizzato e di come accedi alle classi del database, questo potrebbe essere nel costruttore della classe di accesso ai dati.