La configurazione di un'applicazione dovrebbe essere accessibile utilizzando Dal?

Question

La seguente definizione da Wikipedia spiega cos'è il Livello di accesso ai dati in un'applicazione a più livelli.

Un livello di accesso ai dati (DAL) è un livello di un programma per computer che fornisce un accesso semplificato ai dati memorizzati in una memoria persistente di qualche tipo, come un database.

L'archiviazione persistente potrebbe anche consistere in uno o più file, ma i livelli superiori non sanno come ho organizzato le informazioni nei file. Supponiamo di avere un'applicazione che utilizza un file di configurazione, come ad esempio app.config o web.config: nel app.config File potrebbero esserci i valori di alcuni parametri (ad esempio la dimensione massima di una cache), quindi questi valori devono essere caricati durante l'avvio dell'applicazione. Inoltre, se l'applicazione consente la modifica di questi parametri tramite un'interfaccia utente, allora il app.config Il file deve essere aggiornato. Queste operazioni sono parte di Dal?

Answer 1

È sensato un po 'di separazione delle preoccupazioni, in quanto consente di testare i pezzi individualmente più facili poiché non sono gravati dal trattare preoccupazioni specifiche come dove e come la configurazione viene archiviata e recuperata.

Potrebbe essere sensibile creare un modello dei dati di configurazione necessari e accettare questo modello come dipendenza (tramite un costruttore) o se i dati di configurazione sono abbastanza semplici, può essere solo alcune proprietà sul componente stesso.

Nel caso della creazione di un modello per trasmettere informazioni di configurazione, avrai un tempo più facile utilizzando quell'oggetto nella parte dell'applicazione che consente all'utente di interagire con i valori configurabili. L'interfaccia utente per configurare la tua app è una funzione separata in sé.

Ecco un esempio sciocco.

public class Settings
{
    public string SettingOne { get; set; }

    public bool SettingTwo { get; set; }

}

public class DAL
{
    public Settings Settings { get; private set; }

    public DAL(Settings settings)
    {

    }
}

Quindi, se usi i test unitari, puoi testare solo il Dal dandogli le impostazioni che desideri, senza preoccuparsi del pezzo che gestisce le tue impostazioni (sotto c'è un esempio frivolo di un test di nunit).

[Test]
public void Should_do_something_important()
{
    // Arrange
    var dal = new DAL(new Settings { SettingOne = "whatever", SettingTwo = true });

    // Act
    var result = dal.DoSomethingImportant();

    // Assert
    Assert.That(result, Is.Not.Null);
}

Ora, nella tua applicazione, puoi avere un componente separato che gestisce le impostazioni (se scegli così ... forse le tue impostazioni sono davvero abbastanza semplici e questo passo in più non è necessario; dipende da te), su cui puoi testare completamente propria.

public class SettingsManager
{
     public Settings ReadSettings(string path)
     {
         // read from the store

     }

     public void WriteSettings(Settings settings, string path)
     {
        // write settings to the store
     }

}

E un altro test frivolo:

[Test]
public void Should_write_settings_to_store()
{
    // Arrange
    var manager = new SettingsManager();

    // Act
    var settings = new Settings { SettingOne = "value", SettingsTwo = true };
    manager.WriteSettings(settings, @"C:\settings\settings.config");

    // Assert
    Assert.That(File.Exists(@"C:\settings\settings.config", Is.True));
}

Ora nella tua applicazione, puoi fare qualcosa del genere per riunirli:

protected DAL DAL { get; private set; }

public void Init()
{
      var manager = new SettingsManager();

      DAL = new DAL(manager.ReadSettings(@"C:\settings\settings.config"));
}

Il vantaggio di seguire questo percorso è ora il tuo DAL e la gestione delle impostazioni non è accoppiata. Ora puoi costruire e testare i due pezzi in modo indipendente. Lascia che il tuo Dal si concentri sulle cose Dal e le impostazioni di Impostazioni si concentrino sulla gestione delle impostazioni.