Я пишу приложение C#, которое использует длинную строчную кодировку.Используйте внешний файл или ресурс?
Для удобства обслуживания я решил поместить эту строку во внешний текстовый файл и загрузить его. Это хорошая идея? В этом случае дополнительный ввод-вывод не кажется большим.
Я понимаю, что у меня также есть возможность вставить этот файл в качестве ресурса .resx. Это лучшая идея? Файл никогда не должен быть локализован.
Если вы намерены разрешить пользователям/администраторам изменять строку, я согласен с другими ответами, и я предлагаю положить его в настройках.
Если вы не хотите, чтобы он был доступен для редактирования после развертывания, и он будет изменен только вами и вашими разработчиками, я бы поместил его во встроенный ресурс (обратите внимание: это не то же самое, что файл .resx). Вы читали его во время выполнения, как это:
Assembly assembly = Assembly.GetExecutingAssembly();
Stream stream = assembly.GetManifestResourceStream(“MyAssemblyNamespace.MyTextFile.txt”);
StreamReader reader = new StreamReader(stream);
string theText = streamReader.ReadToEnd();
Update: Это решение, которое легко поддерживать. Файл .txt будет просто другим файлом в вашем браузере решений в Visual Studio, и вы можете редактировать его так же, как и любой другой файл, держать его под контролем источника, как и любой другой файл, и т. Д. Чтобы превратить его в встроенный ресурс, изменив Build Действие в окне свойств «Встроенный ресурс».
В результате ваш файл (ы) внедряется в вашу DLL, так что у вас есть только 1 DLL для распространения вместо DLL и папки файлов, которые необходимо перемещать вместе.
Update 2: Что касается «производства отладки», это очень статическое решение, и поэтому вы не сможете изменить содержимое текстового файла во время выполнения, так как файл выпекают в DLL при компиляции время. Для чтения содержимого файла вы можете использовать такие инструменты, как reflector, для просмотра встроенных ресурсов DLL. Вы также можете написать простой инструмент командной строки, который выгружает все встроенные файлы .txt из библиотеки DLL в отдельные файлы для просмотра.
Для использования в памяти нет более эффективного решения, чем «Я загружаю его из файла в память только тогда, когда это необходимо». Вы должны решить, стоит ли улучшенная ремонтопригодность и развертывание, стоит немного дополнительной памяти, когда ваша DLL загружается в память для конкретной ситуации. Тем не менее, вы не сказали, насколько велики эти файлы. Если они действительно огромные (мегабайты +), я бы, вероятно, не использовал это решение и поступил бы с файлами на жестком диске. Если они, как правило, довольно маленькие (сотни килобайт), я бы не стал беспокоиться о дополнительной памяти, если вы не находитесь в какой-то ситуации с встроенным устройством, где оперативная память очень плотная.
Я бы предложил использовать Настройки приложения.
Вы можете следовать этой ссылке MSDN how to use Application and User Settings.
Спасибо, см. Мои другие комментарии - Я не уверен, насколько это масштабируемо это –
Я бы поставил это в application configuration file.
Спасибо, см. Мои другие комментарии - Я не уверен, насколько это масштабируемо это –
Еще лучше добавить файл настроек в ваш проект. Затем вы можете легко добавить настройки конфигурации через Visual Studio. См. this link.
Вы могли бы получить доступ к строке, используя следующие:
Settings.Default.MyString;
Кроме того, настройки сильно типизированных, так что вам не нужно делать каких-либо преобразований, когда вы извлекаете их.
Спасибо - см. Мои комментарии к другим ответам, как это решение удовлетворяет моим требованиям? –
Почему бы не сделать это appSetting в вашем файле 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"];
My .dll реализует точку расширения для другого приложения, поэтому мне не разрешено изменять app.config. Даже если бы я был - app.config загружается при запуске, но моя строка кода никогда не может быть вызвана, поэтому я не хочу эту строку в памяти без причины. Меня больше всего интересует ремонтопригодность: - Какой вариант проще всего обслуживать? - Что будет лучше в случае необходимости «отладки производства»? - Что, если мне понадобится еще много таких файлов? –
Чтобы более точно ответить на ваш вопрос, «лучшей практикой» было бы использовать файл ресурсов для любой локализуемой (даже если вы не собираетесь ее локализовать) в вашем приложении. Это позволяет вам получить доступ к строкам во время компиляции и не использовать его в качестве отдельного файла для развертывания с вашим приложением.
Предлагаю использовать этот подход; настройки аналогичны, но не должны использоваться, если только вы не храните их на самом деле. Константы - это другой вариант, но в случае длинной строки я бы держался подальше от них только ради удобства обслуживания.
Спасибо - см. Мои комментарии к другим ответам, как это решение удовлетворяет моим требованиям? –
Добавлено несколько комментариев об ремонтопригодности ... –
Спасибо, но как насчет: 1. «производственная отладка» - если у меня есть подозрение, что есть проблемы с версией, мне не легче открыть внешний текстовый файл? 2. Предположим, что строка станет очень большой, а также будут другие строки. С вашим решением все они входят в память, когда DLL загружается, а также делает свой размер большим. Когда они являются внешним файлом, они загружаются только тогда, когда (и если) мне они нужны. –