Déclarer des chaînes de caractères public static readonly versus public const versus public static const

Question

Dans chaque projet que nous avons, il y a un fichier utilisé pour stocker les différentes déclarations SQL utilisées dans ce projet. Il existe une poignée de variations sur la façon dont la classe est déclarée et dont les chaînes de caractères sont déclarées.

Exemples de déclarations de classes :

internal sealed class ClassName
internal static class ClassName
public sealed class ClassName
public static class ClassName
internal class ClassName

Exemples de déclarations de chaînes de caractères :

internal const string stringName
internal static string stringName
public static readonly string stringName
public static string stringName
public const string stringName

Je ne comprends pas quelles sont les implications en termes de performances entre les différentes déclarations. Existe-t-il une meilleure pratique pour cette situation/scénario ?

Answer 1

Je ne comprends pas quelles sont les implications en termes de performances entre les différentes déclarations.

Le coût de l'évaluation de la requête de la base de données sera probablement millions o milliards d'euros de fois la différence de coût du passage d'un champ constant à un champ en lecture seule ou vice versa. Ne vous préoccupez même pas des performances de quelque chose qui prend quelques nanosecondes quand vous avez des opérations de base de données dont la latence se mesure en millisecondes.

Ce qui devrait vous préoccuper, c'est la sémantique, pas les performances. La question se résume à "readonly, constant ou ni l'un ni l'autre" ?

La sémantique doit être correcte . Un champ "readonly" signifie "ce champ change exactement une fois par exécution du programme", de null à sa valeur. Un champ "const" signifie "cette valeur ne change jamais, ni maintenant, ni dans la prochaine version, ni jamais, elle est constant à tout moment ." Un champ ordinaire peut changer de valeur à tout moment.

Un champ en lecture seule est quelque chose comme un numéro de version. Il change avec le temps, mais ne change pas au cours de l'exécution du programme. Une constante est quelque chose comme pi, ou le numéro atomique du plomb ; elle est fixe, éternelle, ne change jamais. Un champ ordinaire est bon pour quelque chose qui change au cours de l'exécution du programme, comme le prix de l'or. À quoi ressemble votre requête ? Sera-t-elle constante tout au long de ce programme, constante pour toujours, ou pas constante du tout ?

Answer 2

Vous devez choisir un modificateur d'accès ( public o internal ) en fonction du code qui utilise les chaînes de caractères.

• static const est une erreur de compilation.

• A static readonly est un champ normal qui ne peut pas être défini après le ctor statique.

• A const string sera remplacé par sa valeur littérale au moment de la compilation.
  Par conséquent, les performances seront légèrement meilleures (puisque le moteur d'exécution n'utilise pas le champ).
  Cependant, étant donné qu'elle est substituée au moment de la compilation, tout changement apporté à la définition dans un assemblage ne sera pas pris en compte par les autres assemblages jusqu'à ce qu'ils soient modifiés. todo recompilé.

Si votre code n'est utilisé que dans une seule assemblée, vous pouvez aussi bien utiliser const ficelles.
Cependant, si vos chaînes sont utilisées par d'autres assemblages (ou pourraient l'être à l'avenir), vous devriez utiliser la commande static readonly chaînes de caractères pour la maintenabilité.

Notez également qu'une const est une chaîne temps de compilation constant.
Si vous avez besoin d'inclure des éléments tels que le nom de la machine ou le nom d'utilisateur dans la chaîne de caractères, vous devez faire en sorte qu'il soit static readonly .

Answer 3

Sur const vs static readonly :
const peut avoir de meilleures performances puisqu'il s'agit d'une constante de temps.
Mais d'un autre côté, il y a des problèmes avec les versions binaires. La constante est intégrée dans l'assemblage qui l'utilise, donc si l'assemblage qui la déclare est modifié, l'autre assemblage doit être recompilé ou il utilisera une constante périmée.

Pour les structs, j'utilise généralement une propriété statique au lieu d'un champ en lecture seule, car le jitter peut l'optimiser, mais je n'ai toujours pas de problèmes de versioning.

Answer 4

En termes de vitesse, la différence entre public static string et public const string est négligeable.

En IL, il y a une différence entre

ldsfld someaddr.field 

et

ldstr "your const here"

Mais la réponse est là. En utilisant const, vous obligez littéralement votre assemblage à utiliser ce littéral à chaque fois que vous l'utilisez, et l'assemblage sera donc envahi par ces littéraux. Avec static, ils seront des "pointeurs" vers l'emplacement central.

Le plus gros problème est le suivant : vous ne pouvez pas utiliser le switch case pour les chaînes statiques, mais vous pouvez le faire pour les chaînes const (comme vous le devriez).

Donc, mon point de vue est le suivant : si vous avez besoin d'utiliser switch, vous devez utiliser use const ; si vous n'en avez pas besoin, j'opterais plutôt pour static.

HTH

Nikolai

Answer 5

Étant donné que vous utilisez Visual Studio, un petit avantage pour l'utilisation de public const sur public static readonly c'est la possibilité d'utiliser IntelliSense pour "pointer" à l'écran. const valeur.

Par exemple Étant donné :

public class Constants
{
     public const string ConstString = "Visible!";
     public static readonly string StaticReadonlyString = "Invisible!";
}