Utiliser un fichier externe ou une ressource?

Je suis en train d'écrire une application en C# qui utilise une longue codées "en dur" de la chaîne.

Pour la maintenabilité des raisons que j'ai décidé de mettre cette chaîne de caractères dans un fichier texte externe et de le charger. Est-ce une bonne idée? Le supplément I/O ne semble pas grand dans ce cas.

Je me rends compte que j'ai aussi une option permettant d'incorporer ce fichier comme un .resx de ressources. Est-ce une meilleure idée? Le fichier n'aurez plus jamais besoin d'être localisées.

OriginalL'auteur Yaron Naveh | 2009-05-11

  1. 14

    Si vous souhaitez autoriser les utilisateurs/administrateurs de changer la chaîne, je suis d'accord avec les autres réponses, et je vous suggère de le mettre dans les paramètres.

    Si vous ne voulez pas qu'il soit modifiable après le déploiement, et il va seulement être modifié par vous et vos développeurs, alors je le mettrait dans une ressource incorporée (remarque, ce n'est pas le même que pour un .fichier resx). Vous le lire au moment de l'exécution comme ceci:

    Assembly assembly = Assembly.GetExecutingAssembly();
Stream stream = assembly.GetManifestResourceStream(“MyAssemblyNamespace.MyTextFile.txt”);
StreamReader reader = new StreamReader(stream);
string theText = streamReader.ReadToEnd();

    Mise à jour: C'est la solution qui est facile à maintenir. L' .fichier txt sera juste un autre fichier dans votre explorateur de solutions de Visual Studio et vous pouvez le modifier comme n'importe quel autre fichier, de le garder sous contrôle de code source comme n'importe quel autre fichier, etc. Pour la transformer en une ressource incorporée par l'évolution de l'Action de Construire dans la fenêtre propriétés de "Ressource Incorporée".

    Le résultat final est que votre fichier(s) s'incruster dans votre DLL sorte que vous avez seulement 1 DLL à distribuer au lieu d'une DLL et un dossier de fichiers qui doivent se déplacer ensemble.

    Mise à jour 2: Concernant la production "débogage", c'est un très statique de la solution, et donc vous ne serez pas en mesure de modifier le contenu du fichier texte à l'exécution parce que le fichier est ancré dans la DLL au moment de la compilation. Pour lire le contenu du fichier, vous pouvez utiliser des outils comme réflecteur pour afficher les ressources incorporées d'une DLL. Vous pouvez également écrire un simple outil de ligne de commande qui exporte tous les incorporés .les fichiers txt à partir d'une DLL dans des fichiers individuels pour vous de regarder.

    Pour l'utilisation de la mémoire, il n'y a pas une solution plus efficace que "je le charger à partir d'un fichier dans la mémoire de seulement exactement quand c'est nécessaire". Vous devez décider si l'amélioration de la maintenabilité et de déploiement vaut le cout d'un peu de mémoire supplémentaire lorsque votre fichier DLL est chargé en mémoire pour votre situation spécifique. Cela dit, vous n'avez pas dit combien de grandes ces fichiers sont. Si ils sont vraiment énormes (mo+), je serais probablement pas utiliser cette solution, et va perdre les fichiers sur le disque dur. Si ils sont généralement assez petites (des centaines de kilo-octets), je ne serais pas s'inquiéter à propos de la mémoire supplémentaire, sauf si vous êtes dans une sorte de périphérique intégré situation où la RAM est vraiment serré.

    Merci - voir mon commentaire pour les autres réponses, comment cette solution répond à mes demandes?
    Ajouté quelques commentaires au sujet de la maintenabilité...
    Merci, mais qu'en est: 1. "la production de débogage" - si j'ai quelque soupçon qu'il y a des problèmes de version n'est-il pas plus facile pour moi d'ouvrir le fichier texte externe? 2. Disons que la chaîne va devenir très gros et il y a aussi d'autres cordes. Avec votre solution, ils vont tous en mémoire lorsque la dll est chargée et font aussi de sa grande taille. Lorsqu'ils sont à un fichier externe, ils ne sont chargés que lorsque (et si) j'en ai besoin.
    Yaron, Vos objections et les préoccupations ne semblent pas valide. Tout d'abord, vous avez fait une mauvaise hypothèse. Ressources incorporées dans une assemblée ne sont pas tous chargés en mémoire lors du chargement de la DLL. Deuxièmement, que voulez-vous dire au sujet de "production de débogage". Vos commentaires conserver la mention de cette, mais vous ne vous élaborer sur ce que cela signifie et pourquoi il est un obstacle à l'utilisation de ressources intégrées. La ressource incorporée semble toujours la meilleure idée, de taille raisonnable, des chaînes de caractères.
    Cheeso & Vre - vous semblent contredire si les ressources incorporées sont chargés en mémoire lorsque l'assemblée est - ce qui est le cas?

    OriginalL'auteur Erv Walter

  2. 4

    Pourquoi ne pas en faire un appSetting de votre site web/app.fichier de config? 

    <appSettings>
   <add key="MyLongString" value="This is a really long string value that I don't want hardcoded" />
</appSettings>

    Ensuite, dans le code:

    using System.Configuration;    //To ease your typing pains

var myReallyLongString = ConfigurationManager.AppSettings["MyLongString"];
    Mon .dll implémente un point d'extensibilité pour une autre application, de sorte que je ne suis pas autorisé à changer d'application.config. Même si je serais - app.la config est chargé au démarrage mais ma ligne de code ne peut jamais être appelé si je ne veux pas que cette chaîne de caractères en mémoire pour aucune raison. Je suis surtout intéressé à la maintenabilité: - quelle est l'option la plus facile à entretenir? - Qui sera le meilleur dans le cas où j'ai besoin de "production de débogage"? - Qui, si je vais avoir besoin d'avoir beaucoup plus de fichiers comme celui-ci?

    OriginalL'auteur AJ.

  3. 1

    Je suggère d'utiliser les Paramètres d'Application.

    Vous pouvez suivre ce lien MSDN comment utiliser l'Application et les Paramètres de l'Utilisateur.

    Merci, voir mes autres commentaires - je ne suis pas sûr de la façon évolutive, c'est

    OriginalL'auteur Vadim

  4. 1

    Je mettrais cela dans un fichier de configuration d'application.

    Merci, voir mes autres commentaires - je ne suis pas sûr de la façon évolutive, c'est

    OriginalL'auteur Andrew Hare

  5. 1

    Encore mieux serait d'ajouter un fichier de Settings de votre projet. Vous pouvez facilement ajouter des paramètres de configuration par le biais de Visual Studio.
    Voir ce lien.

    Vous pouvez ensuite accéder à votre chaîne en utilisant les suivantes: 

    Settings.Default.MyString;

    En outre, les paramètres sont fortement typés, de sorte que vous n'avez pas besoin de faire des conversions lorsque vous les récupérer.

    Merci - voir mon commentaire pour les autres réponses, comment cette solution répond à mes demandes?

    OriginalL'auteur Shane Fulmer

  6. 0

    À plus de répondre directement à votre question, les "meilleures pratiques" serait d'utiliser un fichier de ressources pour tout localisables (même si vous n'allez pas à la localiser) chaîne de caractères dans votre application. Cela vous permet de compiler des temps d'accès à la chaîne et l'empêche d'être externalisés dans un fichier distinct pour déployer votre application.

    Je suggère l'utilisation de cette approche; les paramètres sont similaires, mais ne doit pas être utilisé à moins que ce que vous êtes stockage il représente en fait un paramètre. Les constantes sont l'autre option, mais dans le cas d'une longue série, je serais rester loin d'eux, juste pour le plaisir de la maintenabilité.

    OriginalL'auteur Ed Altorfer