Почему люди последовательно рекомендуют использовать appConfig вместо того, чтобы использовать файлы Настроек? (.NET)
Я написал и протестировал нижеприведенное, и он возвращает результат, который вам нужен. Обратите внимание, что это было написано на C # для консольного приложения. Если это поможет, пожалуйста, не забудьте проголосовать за меня.
Создайте свой класс ExerciseOne следующим образом:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace test
{
public class ExerciseOne
{
int[] eo;
public ExerciseOne()
{
eo = new int[10];
for (int i = 0; i <= 9; i++)
{
eo[i] = i + 1;
}
printArrayValues();
}
public void printArrayValues()
{
foreach (var item in eo)
{
Console.WriteLine(item);
}
Console.ReadLine();
}
}
}
Затем вызовите класс следующим образом:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace test
{
class Program
{
static void Main(string[] args)
{
ExerciseOne one = new ExerciseOne();
}
}
}
7 ответов
Я считаю, что самое большое различие между ними состоит в том, что приложение не может изменить значения в app.config. Эти значения читаются во время выполнения, и встроенная поддержка записи новых значений в файл конфигурации отсутствует.
Файлы настроек можно изменить с помощью команды Save().
Одна из основных проблем, связанных со встроенной поддержкой файлов настроек, заключается в том, где хранится файл настроек. Если вы посмотрите на папку APPDATA, то увидите, что есть папка с названием компании, затем подпапка с названием продукта, затем подпапка с полуслучайным именем и информацией о версии. .
Всякий раз, когда вы выпускаете новую версию, он не находит файл настроек из предыдущей версии из-за того, где хранится файл настроек. Также нет способа изменить место хранения файла настроек.
Я использовал его в одном проекте и нашел гораздо более полезным создать свой собственный класс AppSettings, который использует XML-файл для настроек. У меня есть контроль над форматом и расположением файла.
Без обсуждения, тогда ответ:
«Потому что это проще».
Поскольку файловая инфраструктура настроек (1) более сложна и (2) недостаточно документирована, учитывая ее сложность.
Работа файлов настроек по умолчанию полезна для небольших приложений. Для более крупных вам часто нужно изменить это значение по умолчанию. Инфраструктура файлов настроек может использоваться в соответствии с вашими потребностями, но в этом есть крутая кривая обучения, даже с хорошей документацией. Без документации это почти бесполезно.
Я просто ссылаюсь на эту статью, чтобы завершить. Не стесняйтесь вставлять некоторые полезные ссылки на концептуальную документацию MSDN, чтобы противоречить моему аргументу.
Обновление:
Мне нужно быть честным и предоставить конкретный вариант использования, который я не нашел документированным:
Мне нравится конструктор настроек приложения. Мне также нравится формат XML сохраненных настроек. Я хотел сохранить эти функции, но использовать другие места, где хранить настройки. Я не нашел ни единого намека, поддерживается ли этот вариант использования, и если да, как выполнить задачу.
Я также хотел бы отметить одно различие между app.Config и окном настроек. Если вы сохраните что-либо в разделе «Настройки», настройки будут сохранены в следующих местах.
Win XP: c: \ Documents and Settings \% Username% \ Local Settings \ Application Data {Имя издателя} \
Win 7: C: \ Users \% Username% \ AppData \ Local {Publisher Имя} \
Хотя настройки app.config сохраняются только в файле конфигурации.
Неправильно: Отчасти проблема с подходом к файлу настроек заключается в том, что он требует, чтобы приложение находилось в определенном месте, а файл настроек - в правильном месте. Если один из них будет случайно перемещен, настройки могут быть потеряны навсегда, как если бы он был удален. Также может быть проблема с несколькими файлами настроек с одинаковым именем в папке, что приводит к перезаписи одного файла. Это особенно плохо, если программное обеспечение зависит от файла настроек. Эти проблемы не так выражены с установленным программным обеспечением, но в программном обеспечении, которое не установлено, а просто загружено и запущено, может быть серьезной проблемой. Представьте, что кто-то загрузил несколько таких программ в один и тот же каталог, и все они использовали одно и то же имя файла настроек.
РЕДАКТИРОВАТЬ: Как обсуждалось с человеком, задавшим вопрос, этот ответ неверен, потому что вопрос касается двух разных способов сохранения в файл настроек. Когда я дал свой ответ, я подумал, что он имел в виду два разных файла. Единственный ответ, который я могу дать, - это то, что это вопрос личных предпочтений.
Есть третий и намного лучший способ, чем любой другой. AppSettings или Properties: разделы пользовательской конфигурации . Преимущества перед AppSettings:
1) Строго типизированный доступ
2) Встроенные механизмы проверки как для схемы, так и для формы.
3) На основе POCO, что делает его хорошо тестируемым - просто обновите свою собственную тестовую конфигурацию.
4) Не полагайтесь на магические строки. Не то чтобы вы не могли легко обернуть AppSettings в класс и получить к нему доступ таким образом, но 95% разработчиков этого не делают.
5) XML в конфигурации становится намного более понятным, если вы дойдете до дюжины или около того настроек. К тому же он намного более понятен, чем биты Propterties. ИМХО.
6) Не полагаться на визуальную студию, чтобы заставить его работать хорошо.
Конечно, я никогда не использовал свойства, потому что сначала я получил в свои руки разделы пользовательской конфигурации.
Кстати, если вы не слышали об этом, вы все еще используете их каждый день - как вы думаете, что представляют собой стандартные разделы конфигурации в файлах конфигурации .NET?
_____ РАЗДЕЛ УТОЧНЕНИЯ
Во-первых, большая часть этого была направлена на подход AppConfig, и перечитывая мне было непонятно. Я думаю, что в целом мы на одной стороне - избегайте неплотного мешка для конфигурации, потому что он слишком легко ломается. Я также должен добавить, что я веб-парень, поэтому для меня пользовательские настройки находятся на уровне приложения, а не в конфигурации.
1) Верно, как Свойства, так и настраиваемые разделы конфигурации имеют строго типизированный доступ. AppSettings - нет. AppSettings плохой, Props / CC хорош.
2) Когда вы загружаете раздел конфигурации, приложение генерирует исключение конфигурации, если оно не предоставляет необходимую или неправильную информацию. То же, что и при испорчении app.config или web.config. Есть немного более обширная инфраструктура проверки, которую я не использовал, потому что мне нравится отказываться сильно и рано или не отказывать вообще.
3) POCO - простой старый объект C # на тот случай, если кто-то пропустил последние несколько лет. Во всяком случае, поскольку настройки конфигурации являются декоративными и объявляются через атрибуты, ваши настройки конфигурации можно легко протестировать, потому что вам просто нужно выделить новый MyConfigSection () и установить свойства и т. д. в зависимости от ситуации. Насколько я понимаю, у вас должен быть файл конфигурации с правильным xml в нем, иначе вы sol. Другое преимущество состоит в том, что настраиваемые разделы конфигурации работают со всеми остальными полезными вещами, которые вы можете делать с помощью POCO, например, с интерфейсами и внедрением зависимостей.
4) Верно, разделы свойств и настраиваемые разделы конфигурации строго типизированы, а параметры AppSettings - нет. AppSettings плохо, Props / CC хорошо.
5) На самом деле нацелен на AppSettings. Я унаследовал несколько приложений с буквально двумя страницами в конфигурации. Это легко по сравнению с тарабарщиной xml, которую выплевывают свойства. С другой стороны, ваш настраиваемый раздел конфигурации может быть скорее семантическим и не требующим пояснений, поскольку вы объявляете имена и атрибуты разделов. Я могу довольно легко отредактировать его в блокноте на производственном сервере и не слишком нервничать из-за того, что в крайнем случае выстрелит себе в ногу.
Так что, помимо отсутствия сетки свойств на основе VS (что я бы сказал, это плохо вещь - зачем вам сетка для редактирования конфигурации?), пользовательские разделы конфигурации имеют множество преимуществ и не имеют реальных недостатков по сравнению со свойствами. И настраиваемые разделы конфигурации, и свойства имеют огромные преимущества перед AppSettings.
Я могу довольно легко отредактировать его в блокноте на производственном сервере и не слишком нервничать из-за того, что в крайнем случае выстрелит себе в ногу.Так что, помимо отсутствия сетки свойств на основе VS (что я бы сказал, это плохо вещь - зачем вам сетка для редактирования конфигурации?), пользовательские разделы конфигурации имеют множество преимуществ и не имеют реальных недостатков по сравнению со свойствами. И настраиваемые разделы конфигурации, и свойства имеют огромные преимущества перед AppSettings.
Я могу довольно легко отредактировать его в блокноте на производственном сервере и не слишком нервничать из-за того, что в крайнем случае выстрелит себе в ногу.Так что, помимо отсутствия сетки свойств на основе VS (что я бы сказал, это плохо вещь - зачем вам сетка для редактирования конфигурации?), пользовательские разделы конфигурации имеют множество преимуществ и не имеют реальных недостатков по сравнению со свойствами. И настраиваемые разделы конфигурации, и свойства имеют огромные преимущества перед AppSettings.
Два сценария:
- Клиентское приложение, которое поставляется с параметрами конфигурации, установленными на значения по умолчанию. Приложение предоставляет пользовательский интерфейс для изменения настроек для одного или всех пользователей.
Здесь выигрывает подход «настройки».
- Приложение, состоящее из нескольких относительно независимых сборок, каждая из которых требует нескольких простых настроек конфигурации. . Настройки обычно устанавливаются администратором и не изменяются приложением после развертывания.
Здесь "appSettings" может быть намного проще управлять. При использовании подхода «настройки» для каждой настраиваемой сборки будет отдельный раздел, который будет добавлен в файл конфигурации основного приложения.