Sollten DLLs eigene Konfigurationsdateien haben?

Question

Entschuldigung, wenn dies ein Duplikat ist, aber ich habe es nicht geschafft, diese Frage direkt zu stellen.

Die allgemeine Meinung hier (das bin ich und er gegenüber von mir) ist, dass sie nicht sollten, der Grund ist, dass DLLs geteilt werden können; Daher ist die Idee, anwendungsspezifische Informationen in einer DLL zu haben, Unsinn. Wenn die Information nicht anwendungsspezifisch ist, können Konstanten verwendet werden. Eine weitere Frage ist, angenommen, dass DLLs keine eigene Konfigurationsdatei haben, ob DLLs die Konfigurationsdateien der ausführbaren Datei verwenden sollten, die die DLL geladen hat, oder stattdessen die relevanten Daten als Teil eines Konstruktors übergeben werden. Unsere Meinung ist hier die letztere, da sie es testbarer macht, der Nachteil ist, dass es manchmal notwendig sein wird, eine signifikante Menge von Daten an die DLL zu übermitteln.

Meinungen?

Answer 1

Es gibt keinen Grund, warum Sie nicht das Beste aus beiden Welten in Bezug auf haben kann "Einfach mit Config-Dateien zu konfigurieren" und "testbar". Verfügen über eine statische Methode, die Instanzen aus der Konfigurationsdatei erstellen kann, aber auch einen Konstruktor für mehr Kontrolle und Testbarkeit bereitstellen. Die statische Methode würde einfach die Einstellungen übernehmen und den Konstruktor aufrufen.

Ich glaube, es ist möglich, Einstellungs-Klassen für DLLs wie jedes andere Projekt zu erstellen, und dann müssen Sie nur den tatsächlichen Text in die Konfigurationsdatei der Anwendung anstelle von einem für die DLL setzen. Ignorieren Sie grundsätzlich die Datei "app.config", die für das Bibliotheksprojekt generiert wurde, mit Ausnahme der Verwendung als Vorlage für die zentrale Anwendung der Anwendung.

Alternativ verwenden Sie etwas wie Spring.NET, um diese Art von Sache zu verwalten :)

Answer 2

Normalerweise sollten Sie relevante Informationen an die Funktionen übergeben, die Sie aufrufen, oder relevante Eigenschaften in Objekten festlegen, die Sie erstellen, die in der DLL definiert sind. Ich denke, das ist, warum .NET Konfigurationsdateien für DLLs nicht wirklich unterstützt (Sie können sie erstellen, aber sie werden nicht verwendet, wenn sie ausgeführt werden).

Ich habe ein Szenario, wo DLLs eine Konfigurationsdatei lesen, aber das ist sehr speziell: Die .NET DLL exportiert Objekte als COM-Objekte für die Verwendung von Microsoft Navision. Es kommuniziert mit einer Factoring-Bank über eine XML-RPC-Schnittstelle.

Während die DLL auf dem Computer jedes Benutzers installiert ist, ist die Konfiguration für die Schnittstelle allen Benutzern gemeinsam. Daher habe ich eine Konfiguration auf einem Netzwerklaufwerk, das auf jedem PC und der Konfiguration zugeordnet ist (URL, Anmeldeinformationen usw.).) wird von dieser gemeinsamen Datei gelesen.

Ob das eine gute Praxis ist für den Leser, aber in diesem Szenario eine gemeinsame Konfigurationsdatei, die nur Sinn gemacht ...