Hat irgendjemand viel darüber nachgedacht? Persönlich halte ich die Verwaltung von Endpunkten in Konfigurationsdateien für eine Belastung. Gibt es irgendwelche Vor-und Nachteile für die anderen?Programmgesteuerte Konfiguration von Endpunkten vs. web/app.config
Nur Punkte für Konfigurationsdateien von mir.
Verwalten von Endpunkten in Konfigurationsdateien bedeutet, dass Sie Ihre Anwendung nicht aktualisieren müssen, wenn (oder vielleicht sollte ich sagen, wann) die Endpunkte ändern.
Sie können auch mehrere Instanzen der Anwendung mit verschiedenen Endpunkten ausführen.
Offensichtlich muss ein Endpunkt in einer Konfigurationsdatei nicht neu kompiliert werden, wenn er geändert wird. Dies bedeutet auch, dass Sie Ihre Konfigurationsdatei nur aktualisieren müssen, wenn Sie eine Anwendung von Entwicklung zu UAT zu Produktion verschieben.
Wenn Sie nur etwas für sich selbst zu Hause programmieren, dann gibt es keinen wirklichen Unterschied. In einer Geschäftsumgebung können Sie jedoch mit dem in Ihrer Konfigurationsdatei definierten Enpoint alle möglichen Probleme vermeiden.
Es ist nur eine Frage, wie viel Flexibilität Sie benötigen. Normalerweise bevorzuge ich den Ansatz der Konfigurationsdatei.
Wenn Sie eine app.config verwenden, muss Ihre Anwendung nicht erneut kompiliert werden, um sie an eine Änderung anzupassen. Außerdem kann es in mehreren Situationen mit genau demselben Code erneut verwendet werden. Schließlich ist das Kodieren Ihrer Endpunkte (oder irgendetwas, das sich ändern kann) eine schlechte Kodierungspraxis. Haben Sie keine Angst vor der Konfigurationsdatei, es ist deklarative Programmierung. Sie sagen: "Ich möchte diesen Endpunkt verwenden." und es macht die Arbeit für dich.
Ich neige dazu, die Config-Ansatz auch gerne selbst, außer der Config-Datei kann ziemlich groß werden.
Das einzige, was ich mit WCF Konfiguration bemerkt habe ist, dass es eine Menge Sachen, die Sie von Code tun können, die Sie ohne Zusatz Ihre eigenen Erweiterungen in XML-Konfigurations nicht tun. Mit anderen Worten, das Ausführen von Config in Code wird mehr Flexibilität ermöglichen, natürlich könnten Sie auch Ihre eigenen Erweiterungen programmieren und diese aus der Konfiguration verwenden.
Beachten Sie jedoch, dass es einen Fehler in Visual Studio gibt, der, wenn Sie anfangen, Ihre eigenen Erweiterungen zu erstellen und sie in XML einzuschließen, VS Ihre Konfigurationsdatei nicht mehr mögen und markieren wird Wenn Sie versuchen, einen neuen Dienst über die Assistenten hinzuzufügen, wird der Endpunkt der Konfiguration nicht hinzugefügt. Diese
ist das für einen Followup auf meine eigene Antwort:
Nach Monaten alles in XML-Konfiguration, ich bin alles, was eine Änderung der Endpunkte und Bindungen in Code zu konstruieren. Ich fand einen wirklich guten Fall dafür, es im Code zu haben;
Wenn Sie eine bereitstellbare/gemeinsam nutzbare .dll haben möchten, die WCF-Clients enthält.
Wenn Sie beispielsweise eine CommonClients.dll haben, die alle Ihre WCF-Schnittstellen und Verträge für die Kommunikation mit einem Remote-Server enthält, möchten Sie nicht auch sagen: "Hier sind 100 Zeilen XML, die Sie ebenfalls benötigen Für jeden Client in die app.config einfügen, damit er funktioniert. " Alles in Code zu konstruieren funktioniert in diesem Fall viel besser.
Es gibt auch ein "Feature" von .NET 3.5, wo, wenn Sie einige Erweiterungen haben, müssen Sie den voll qualifizierten Assemblynamen angeben. Das bedeutet, wenn Ihre Assembly, die die Erweiterungen enthält, die Versionsnummer ändert, müssen Sie auch den Assemblynamen in der Konfigurationsdatei ändern. Es wird angeblich in .NET 4 behoben, um einen kurzen Assemblynamen zu verwenden und nicht den vollständigen Namen zu erfordern.
Ich mache im Allgemeinen Programmatic-Konfiguration, wie ich meine Anwendungen interne Struktur der Benutzer nicht offenlegen möchte. Die einzige Sache, die ich konfigurierbar halte, ist Service-Adresse, aber selbst das halte ich im userSettings Abschnitt, nicht system.ServiceModel.
Ich bevorzuge und empfehle die Konfigurationsdatei Ansatz. Es bietet eine große Flexibilität, da Änderungen auf Ihrem Server vorgenommen werden können, ohne dass die Anwendung neu kompiliert werden muss. Wenn Sie Sicherheit benötigen, können Sie die Konfigurationsdatei verschlüsseln.
Die größte Sorge bei einfachen Konfigurationsdateien könnte sein, dass sie versehentlich (oder absichtlich) vom Endbenutzer geändert werden, was zum Absturz Ihrer App führt. Um dies zu umgehen, könnten Sie einige Tests im Code durchführen, um zu überprüfen, ob die Konfiguration in der Konfigurationsdatei in Ordnung ist, und falls nicht, initialisieren Sie sie programmatisch auf einige Standardwerte. Ich stellte vor, wie Sie das in einer anderen Antwort auf this Frage tun könnten.
Überprüfen Sie die .NET StockTrader app. Es verwendet ein Repository zum Speichern von Konfigurationsdaten und verfügt über eine separate App zum Verwalten der Konfiguration. Die Einrichtung und Struktur ist ziemlich fortgeschritten und es gibt ein bisschen Kopfschütteln für jemanden wie mich, der bisher nur die Grundlagen der WCF-Konfiguration hat, aber ich würde sagen, dass es einen Blick wert ist.