4

我正在编写一个使用长“硬编码”字符串的 C# 应用程序。

出于可维护性的原因，我决定将此字符串放在外部文本文件中并加载它。这是一个好主意吗？在这种情况下，额外的 I/O 似乎并不大。

我意识到我还可以选择将此文件嵌入为 .resx 资源。这是一个更好的主意吗？该文件永远不需要本地化。

4

6 回答 6

15

如果您打算允许用户/管理员更改字符串，我同意其他答案，我建议将其放入设置中。

如果您不希望它在部署后可编辑并且只能由您和您的开发人员修改，那么我会将其放入嵌入式资源中（注意，这与 .resx 文件不同）。你会在运行时像这样阅读它：

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

更新：这是易于维护的解决方案。.txt 文件将只是 Visual Studio 中解决方案资源管理器中的另一个文件，您可以像编辑任何其他文件一样对其进行编辑，像任何其他文件一样将其置于源代码控制之下，等等。通过更改 Build 将其变成嵌入式资源在属性窗口中对“嵌入式资源”进行操作。

最终结果是您的文件被嵌入到您的 DLL 中，因此您只有 1 个 DLL 可以分发，而不是一个 DLL 和一个必须一起移动的文件文件夹。

更新 2：关于“生产调试”，这是一个非常静态的解决方案，因此您将无法在运行时更改文本文件的内容，因为该文件在编译时被烘焙到 DLL 中。为了读取文件的内容，您可以使用反射器等工具来查看 DLL 的嵌入式资源。您还可以编写一个简单的命令行工具，将所有嵌入的 .txt 文件从 DLL 转储到单独的文件中供您查看。

对于内存使用，没有比“我只在需要时才将它从文件加载到内存中”更有效的解决方案。当您的 DLL 针对您的特定情况加载到内存中时，您必须确定改进的可维护性和部署是否值得花费一点额外内存。也就是说，您还没有说这些文件有多大。如果它们真的很大（兆字节+），我可能不会使用这个解决方案，并且会在硬盘驱动器上使用松散的文件。如果它们通常很小（数百千字节），我不会担心额外的内存，除非您处于 RAM 非常紧张的某种嵌入式设备情况。

于 2009-05-11T15:54:25.253 回答
4

为什么不在您的 web/app.config 文件中将其设置为 appSetting？ 

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

然后，在代码中：

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

var myReallyLongString = ConfigurationManager.AppSettings["MyLongString"];
于 2009-05-11T15:50:12.890 回答
1

我建议使用应用程序设置。

您可以按照此 MSDN 链接如何使用应用程序和用户设置。

于 2009-05-11T15:48:53.733 回答
1

我会把它放在一个应用程序配置文件中。

于 2009-05-11T15:49:39.787 回答
1

更好的方法是将设置文件添加到您的项目中。然后，您可以通过 Visual Studio 轻松添加配置设置。请参阅此链接。

然后，您可以使用以下命令访问您的字符串：

Settings.Default.MyString;

此外，设置是强类型的，因此您在检索它们时不需要进行任何转换。

于 2009-05-11T15:49:41.300 回答
0

为了更直接地回答您的问题，“最佳实践”是在您的应用程序中为任何可本地化（即使您不打算对其进行本地化）字符串使用资源文件。这允许您在编译时访问字符串，并防止它被外部化为单独的文件以与您的应用程序一起部署。

我建议使用这种方法；设置是相似的，但除非你存储在那里的内容实际上代表了一个设置，否则不应使用它。常量是另一种选择，但在长字符串的情况下，我会远离它们，只是为了可维护性。

于 2009-05-11T19:04:11.293 回答