J'ai une variable de chaîne statique que je dois changer éventuellement en fonction du protocole HTTP.
est-il une mauvaise pratique de modifier la variable de chaîne statique> Merci
8 Réponses :
Non. Bien sûr, vous pouvez modifier la valeur d'une variable de chaîne statique. Pourquoi pensez-vous que c'est un mauvais prix?
En effet pas une mauvaise pratique. Mais la raison de l'OP, telle qu'elle est, je suis sûr de faire avec le fait que les champs statiques mutables sont sujets aux problèmes de filetage. (Tout comme tous les champs, bien sûr, mais les champs statiques sont plus susceptibles d'être partagés sur des threads que des champs d'instance.)
Je suis surpris que cela a eu tellement de susvotes étant donné des conséquences probablement désastreuses dans un environnement multi-fileté.
@Captaintom: Je n'ai vu nulle part OP dit qu'il tente de charger des paramètres simultanément. Nous ne supposerons pas que c'est un programme multi-thread par défaut, non? Sinon, beaucoup de réponses sont incorrectes.
Toujours prendre en considération multi-filetage lors de la gestion des statiques qui changent au moment de l'exécution.
@Captaintom: je suis en désaccord. Considérez de nombreuses classes intégrées, elles sont documentées comme sans fil.
Je veux dire, modifier une variable statique est un non-problème. C'est une variable. Cela peut varier. Alors, pourquoi varierait (c'est-à-dire la modification) être une mauvaise pratique? Oui, il y a des situations où vous ne devriez pas ou ne devez pas faire attention si vous le faites, mais en général, ce n'est pas le cas.
Le gros problème ici consiste à lire les paramètres d'application au fond des courants de votre application. Il tue la maintenabilité et la testabilité. C'est une pratique horrible et je vous encourage à vous arrêter immédiatement.
Je ne peux pas changer la chose des paramètres de l'application car il s'agit d'une application d'entreprise, je travaille simplement sur la modification des modules. Merci encore cependant
Parler par programme, de la langue POV, il est correct de le changer.
Dépend sinon la logique de la variable, le sens qu'il a dans la logique commerciale globale.
Dans ce cas, il semble que c'est juste une installation ponctuelle, mais vous devez être conscient des conditions de race dans un environnement multithread, y compris ASP.NET.
Non, ce n'est pas une mauvaise pratique dans général . Dans votre affaire
seul, changer une variable statique n'est pas une mauvaise chose.
Cependant, je ne vois aucune précaution prise concernant plusieurs instances de cette classe modifiant la même statique. C'est une question de concurrence potentielle.
En outre, vous devez probablement définir les deux paramètres de la statique et choisir celui qui convient parfaitement sur votre condition, mais laissez la statique seule une fois qu'ils sont initialisés.
Vous pouvez utiliser une propriété statique au lieu d'une variable statique.
private static string QuoteWebServiceUrl
{
get
{
if(url == "https")
{
return CommonFunctions.ReadAppSetting("QuoteWebServiceUrlSecure");
}
else
{
return CommonFunctions.ReadAppSetting("QuoteWebServiceUrl");
}
}
}
Cela ne fait rien pour répondre à la question posée.
pour Il existe une logique commerciale où il n'y a qu'un seul fil à la fois pour traiter ou Dans ces cas, il est bon d'avoir et que nous ne pouvons parfois pas avoir d'autres options plutôt modifiées (l'un des cas est avec lors de l'utilisation de webapi avec une tâche asynchrone et, plus important encore, un seul fil à l'heure et l'utilisateur veut une mise à jour de statut dynamique pour chaque API HIT)
Je pense que vous avez mal compris le concept de statique et / ou de le confondre avec const. De plus, l'essentiel de votre code est inutile, car CroewebSserviceURL sera déjà égal à la valeur que vous définissez.
Je pensais que cela pourrait être un problème de filtration. Le si / sinon était juste une maquette aléatoire de ce que je fais merci pour votre aide