In che modo altri sviluppatori sanno che la libreria di classi sta utilizzando app.config? O dovrei semplicemente eliminare app.config?

Question

Proprio come un esempio, ho creato una libreria di classi (Email.DLL) che invia un'email. Per inviare un messaggio di posta elettronica, le credenziali di fabbisogno SmtpClient, che vengono attualmente lette da app.config.

Così ora ho creato un'app console separata (SendStuff.exe) che invia un'email, quindi ho aggiunto Email.dll come riferimento. Essendo quello che ha creato sia la DLL sia l'app per console, so che ho bisogno di aggiungere le chiavi appropriate nell'app della console appSettings di app.config per poter inviare l'email.

Ora, supponiamo che qualcun altro utilizzi la DLL. Come fa a sapere che la sua applicazione deve includere l'appropriato appSettings in modo che il mio Email.DLL possa inviare l'e-mail?

O sarebbe meglio eliminare semplicemente app.config dalla libreria di classi e trovare un altro modo per impostare le credenziali?

Answer 1

L'utilizzo del file di configurazione locale è un approccio perfettamente standard. Di solito, dovresti includere queste informazioni nella documentazione che accompagna la libreria. Spesso, c'è una paginaTutorialper iniziare.

Detto questo, mi piacerebbe anche attuare chiaro e attuabili eccezioni generate quando questi valori di configurazione sono mancanti. Qualcosa di simile:

Impossibile trovare le credenziali SMTP in App.config. Vedere la documentazione per ulteriori informazioni.

Infine, se si distribuisce la libreria con qualcosa di simile NuGet, si può automaticamente include default configurations che verrà impostato quando la libreria viene aggiunto tramite il gestore di pacchetti.

Answer 2

Mi vengono in mente due approcci di alto livello, a seconda della risposta a una domanda ...

• Questo Library Riepilogo suoi dettagli di implementazione del codice di consumo?

Se "sì", fornirei alla libreria un esempio app.config per dimostrare come configurarlo. Quando viene caricata la libreria, può verificare i valori di configurazione e generare un'eccezione se non sono disponibili. Questo potrebbe essere utile nel caso di, ad esempio, un'interfaccia di messaggistica generica in cui consumare il codice non ha bisogno di sapere se si tratta di e-mail:

public class Messenger : IMessenger 
{ 
    public Messenger() 
    { 
     // maybe confirm config values here 
    } 

    public void Send(string message, User recipient) 
    { 
     // implementation details 
    } 
} 

Rendere l'eccezione molto esplicita in modo che sia evidente quale sia il problema.

Se, invece, la risposta è "no" e non è necessario che la "SMTP-ness" della libreria sia dietro un'interfaccia più astratta, la libreria può richiedere altrettanto facilmente la configurazione quando lo usi:

public class Messenger 
{ 
    public Messenger(string smtpServer, int port) 
    { 
     // set the local class values from the supplied values 
    } 

    public void Send(string message, string recipientEmail) 
    { 
     // implementation details 
    } 
} 

Questo disaccoppia completamente la libreria dai dettagli di configurazione e forza il codice di consumo a fornire tali valori.Per lo sviluppatore che usa la libreria, questo è molto più ovvio. Tuttavia, richiede che i dettagli di implementazione siano esposti staticamente dal codice, quindi è meno astrazione. Pro e contro in entrambi i casi.

Answer 3

A mio parere è meglio non leggere le credenziali all'interno della libreria. Lascia che il chiamante passi le credenziali al client smtp.

es .:

SmtpClient client = new SmptClient(string username, string password); 

Questo rende evidente al consumatore ciò che deve fare in modo che possa utilizzare la classe. Il consumatore può ancora decidere di memorizzare il nome utente/password nell'app.config o tirare le credenziali da qualche altra parte (ad esempio un database).

Sono d'accordo che l'uso di app.config non è raro, ma lo suggerirei solo se i dati non possono essere facilmente passati al componente all'interno del codice.

Anche se la struttura dei dati è complicata (ad esempio la configurazione di un logger) è comunque necessario dare al consumatore la possibilità di utilizzare il componente esclusivamente dal codice. Quindi ad es. log4net di solito è configurato con un file di configurazione, tuttavia puoi sempre usare il metodo Configure() per aggirarlo.

log4net.Config.XmlConfigurator.Configure(XmlElement element)