2009-06-12 4 views
0

Angenommen, ich habe eine große .NET-Lösung, die über einige Datenzugriffsprojekte verfügt, die von einigen anderen Projekttypen wie einer Konsolenanwendung und einer Webanwendung verwendet werden. Ich möchte, dass beide das Datenzugriffsprojekt verwenden können, aber die App für den Datenzugriff muss die Konfiguration aus ihrer Konfigurationsdatei entnehmen ... also web.config für das Webprojekt und app.config für die Konsole/Service-Apps. Dies führt dazu, dass ich die Konfiguration in zwei oder mehr separaten Konfigurationsdateien verwalten muss, was ich nicht mag. Was ist der beste Weg, sie an einen zentralen Ort zu bringen?.NET: zentralisierte Split-Konfiguration

Ich möchte, dass es immer noch leicht ist, also könnte eine Konfigurationsdatenbank übertrieben sein. Ich denke vielleicht eine zentralisierte Konfigurationsdatei, die durch den Build-Prozess in web.config/app.config kopiert wird, wenn die jeweiligen Projekte gebaut werden, aber ich wollte sicherstellen, dass ich nicht irgendwo eine andere Best Practice verpasse. Ich habe auch über machine.config nachgedacht, aber ich möchte Konfiguration so viel wie möglich isolieren, um andere Anwendungen auf einem gegebenen Computer möglicherweise nicht zu stören. Und mithilfe von machine.config müsste ich herausfinden, wie das Build-Skript die Datei automatisch per Fernzugriff aktualisieren kann.

Antwort

1

Dieses Modell funktioniert ziemlich gut - die meisten unserer wichtigeren Apps sind Multi-Headed-Biester mit mehreren Web- und Befehlszeilen-Apps, die einige der gleichen Konfigurationsinformationen teilen müssen. Ein guter Trick besteht darin, die configSource Eigenschaft der Konfigurationselemente zu missbrauchen, um die "zentralen" Teile aus den anwendungsspezifischen Teilen herauszubrechen.

2

Ein paar mögliche Lösungen:

  1. Wenn alle Ihre Lösungen werden an den gleichen Ort (zB ein Web-Server/Farm) eingesetzt werden, könnten Sie die machine.config Datei verwenden gemeinsamen Datenzugriff zu speichern config wie Verbindungszeichenfolgen.

  2. Teilen Sie Ihre allgemeine Konfiguration in eine separate Konfigurationsdatei (z. B. common.config) und verwenden Sie das Attribut configSource in den Hauptkonfigurationsdateien, um auf das allgemeine zu verweisen. Wenn Sie eine Art Quellcodeverwaltung verwenden, sollten Sie die gemeinsame Datei zwischen Projekten freigeben. Eine Änderung würde dann von allen verwendet, die sie verwenden.

0

Wie wäre es damit:

  • Definieren Sie Ihre "dev/Staging/Produktion" Einstellungen in der Konfigurationsdatei des Datenzugriffs-Projekt

  • die Kunden (Apps) Lassen Sie definieren, was Art der Einstellungen, die sie verwenden möchten, z das Modul Data Access -

... = DataAccess.UserGateway.Create(DataAccess.Config.Dev);

und die String-Konstanten für die Namen der verschiedenen Konfigurationen sind nur an einer Stelle definiert ist.

Auf der anderen Seite, ich bin viel für das Kopieren von Konfigurationen bei Build/Deployment-Zeit - es ist so sauber.

Verwandte Themen