Использовать внешний файл или ресурс?

Question

Я пишу приложение на C #, которое использует длинную «жестко закодированную» строку.

В целях удобства обслуживания я решил поместить эту строку во внешний текстовый файл и загрузить ее. Это хорошая идея? В этом случае дополнительный ввод / вывод не кажется большим.

Я понимаю, что у меня также есть возможность встроить этот файл в качестве ресурса .resx. Это лучшая идея? Файл никогда не нужно будет локализовать.

Answer 1

Если вы хотите разрешить пользователям / администраторам изменять строку, я согласен с другими ответами и рекомендую установить ее в настройках.

Если вы не хотите, чтобы оно было редактируемым после развертывания, и оно будет изменено только вами и вашими разработчиками, то я бы поместил его во встроенный ресурс (обратите внимание, это не то же самое, что файл .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 загружена в память для вашей конкретной ситуации. Тем не менее, вы не сказали, насколько велики эти файлы. Если они действительно огромные (мегабайт +), я бы, вероятно, не использовал бы это решение и пошел бы с незакрепленными файлами на жестком диске. Если они, как правило, довольно малы (сотни килобайт), я не стал бы беспокоиться о дополнительной памяти, если только вы не находитесь в какой-то ситуации со встроенным устройством, где ОЗУ очень мало.

Answer 2

Почему бы не сделать это установкой приложения в файле web / app.config?

<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"];

Answer 3

Еще лучше было бы добавить файл настроек в ваш проект. Затем вы можете легко добавить параметры конфигурации через Visual Studio. Смотрите эту ссылку .

Затем вы можете получить доступ к вашей строке, используя следующее:

Settings.Default.MyString;

Кроме того, настройки строго типизированы, поэтому вам не нужно выполнять какие-либо преобразования при их получении.

Answer 4

Я бы поместил это в файл конфигурации приложения .

Answer 5

Я бы предложил использовать настройки приложения.

Вы можете перейти по этой ссылке MSDN , как использовать настройки приложения и пользователя .

Answer 6

Чтобы более прямо ответить на ваш вопрос, лучше всего использовать файл ресурсов для любой локализуемой (даже если вы не собираетесь ее локализовать) строки в своем приложении. Это позволяет вам получить доступ к строке во время компиляции и не допустить ее вывода в виде отдельного файла для развертывания вместе с приложением.

Я предлагаю использовать этот подход; настройки похожи, но их не следует использовать, если то, что вы храните там, на самом деле не представляет настройки. Константы - это другой вариант, но в случае длинной строки я бы держался от них подальше, просто ради удобства обслуживания.