C# SETTINGS architecture

Question

J'ai plusieurs applications qui ont besoin de lire et d'écrire les paramètres de l'application. Puisque l'une des applications est une ancienne application C++ avec des centaines de paramètres dans le registre (et qui ne change pas) et il y a aussi quelques paramètres stockés dans un format de base de données propriétaire, je me demande comment l'architecture pourrait être configurée autoriser une seule interface pour lire et/ou écrire les paramètres. Une idée est qu'il y ait une énumération géante avec tous les paramètres possibles et une division qui dirige la demande de lecture/écriture, basée sur une déclaration de cas géante, vers le lecteur ou l'auteur correct. Dans le cas du registre, il faudrait ensuite analyser les possibilités d'enum pour trouver l'emplacement de la clé (si c'est un paramètre Http ici, si c'est un paramètre d'installation situé à cette touche). Toute cette idée me fait penser à la non-OOP et trop de tests manuels. Gardez à l'esprit qu'il existe environ 30 paramètres de base de données, et peut-être 70 paramètres de registre.

public class SettingsTest 
{ 
    public enum ESetting 
    { 
     HttpUserName, HttpPassword, SetupAllowPublic, //db server stored 
     HttpProxyUsername, HttpProxyPassword, PublicOrPrivate //registry stored 
    } 

    public string GetSetting(ESetting setting) 
    { 
     if (IsSettingInRegistry(setting) 
      return RegHandler.GetFromRegistry(setting); 
     else 
      return DBHandler.GetFromDB(setting); 
    } 
} 

Answer 1

Je pense que le « grand » ENUM pourrait être un peu méchant - pourquoi ne pas les briser à l'aide des espaces de noms; à quote MSDN:

Habituellement, il est préférable de définir un ENUM directement dans un espace de noms afin que toutes les classes dans l'espace de noms peut accès avec facilité égale. Cependant, un ENUM peut également être imbriquée au sein d'une classe ou struct

Alors vous pourriez avoir:

RediVider.EnterpriseApp.DataAccess.ESettingsKeys 
RediVider.EnterpriseApp.BusinessLogic.ESettingsKeys 
RediVider.EnterpriseApp.ComponentXXX.ESettingsKeys 

aussi - ce que vous déclarerait énumérations, ou des champs statiques en lecture seule? (où la valeur est la clé, et en supposant que lorsque vous définissez une clé, vous expliquez d'où elle vient - d'où la valeur de la clé). Une meilleure idée serait de ne pas définir une clé spécifique au référentiel, mais une clé qui correspond à une clé AppSetting - et c'est là que vous avez défini la clé spécifique au référentiel. Cela vous permettrait de changer d'endroit pour obtenir le "paramètre" de - via la configuration, et sans avoir à redéployer l'application.

Donc, vous avez:

namespace RediVider.EnterpriseApp.DataAccess 
{ 
    Public class ESettingsKeys 
    { 
    // Note - AppSetting Keys are "namespaced" to match: 
    public readonly string SetupAllowPublic = "RediVider.EnterpriseApp.DataAccess.SetupAllowPublic"; 
    } 
} 

Ensuite, dans votre config (code psuedo):

<AppSetting Key="RediVider.EnterpriseApp.DataAccess.SetupAllowPublic" value="/System/Settings/Blah/SetupAllowPublic"> 

Le seul hic est que cela ne contribue à briser-les clés dans plus logique et plus facile à traiter avec les zones - vous avez encore la question de la résolution du référentiel. Si vous voulez vraiment faire abstraction que sur vous auriez besoin de sérialisation une classe simple qui avait

• Key
• Valeur
• dépôt

L'idée de l'instruction switch est pas mauvais, mais vous pouvez adopter la même approche ici, en utilisant une sorte d'approche basée sur les modèles de façade ou d'usine:

• méthodes qui obtiennent les paramètres du référentiel de stockage.
• Dans chaque espace de noms (selon les ESetting enums), vous disposez d'une méthode "GetSettings" qui fait ce que vous avez décrit, mais uniquement pour les paramètres définis dans cet espace de noms.