Когда использовать константы или файлы конфигурации для поддержки конфигурации

Я часто бьюсь с собой о том, нужно ли помещать определенные ключи в мой web.config или в класс Constants.cs или что-то в этом роде.

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

Когда вы хотите использовать константы поверх ключей конфигурации?

Этот вопрос действительно относится к любому языку, я думаю.

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

Если приложение принимает аргументы командной строки, они, в свою очередь, переопределяют параметры файла конфигурации.

Значение в файле конфигурации сложнее поддерживать, чем значение в классе констант, потому что компилятор не проверяет его существование и имеет правильный тип, IDE обычно не предоставляет помощь по коду для него, а также потому, что это еще один синтаксис, на который нужно переключиться во время программирования.

Поэтому я бы предложил поставить:

• Значения, которые будут одинаковыми во всех установках с константами в коде. Есть некоторые преимущества в том, что они помещаются в один класс констант (вы можете легко опробовать различные значения, чтобы увидеть, как они работают) и помещаете их в модуль, который их использует (вам не нужно открывать еще один файл при изменении этого модуля и избегая одного файла, который каждый мог бы редактировать, вызывая конфликты в управлении версиями).
• Значения, которые (возможно) необходимо изменить для каждой установки в конфигурационном файле. И, возможно, вы все равно захотите установить значение по умолчанию в коде, поэтому, если значение не установлено в конфигурации, приложение все равно (как-то) работает.

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

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

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

Когда есть много элементов конфигурации, которые относятся к разным объектам, не связанным друг с другом, и когда такому количеству объектов необходимо извлечь (одинаковые или свои) файлы конфигурации, есть вероятность, что эти вещи должны быть константами.

Простое практическое правило заключается в создании констант, когда вы знаете, что будете работать с фиксированным набором значений, которые, как вы знаете, могут применяться для любого данного контекста без необходимости их изменения; обеспечить внешние конфигурации для всего остального.

Хорошим примером констант было бы, если бы все фигуры, с которыми вы работали, могли быть SQUAREили ROUND. В большинстве языков вы сможете использовать тот факт, что это значение не изменяется со временем, выделив его только один раз и оптимизировав доступ к нему.

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

Вы также можете просто использовать этот шаблон проектирования: «соглашение о конфигурации».

http://msdn.microsoft.com/en-us/magazine/dd419655.aspx http://en.wikipedia.org/wiki/Convention_over_configuration

Константа по определению - это область памяти для значения, которое не должно изменяться (например, PI).

Я предполагаю, что вы имели в виду «параметр», а не константа

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

По возможности не выставляйте значения в конфигурационном файле, не проверяя их в коде для проверки работоспособности. Кроме того, я предлагаю не размещать параметры бизнес-правил (например, максимальную зарплату и т. Д.) В файлах конфигурации и не использовать константы для них. Такие значения должны храниться в базе данных с соответствующими определениями таблиц, чтобы обеспечить некоторую безопасность при их изменении, и вы можете автоматически создавать версии значений данных (используя сохраненные журналы procs или db). Конечно, это зависит от того, насколько чувствительно ваше приложение.

Если вы когда-либо используете файлы конфигурации для хранения данных, убедитесь, что вы их версии.