Я часто бьюсь с собой о том, нужно ли помещать определенные ключи в мой web.config или в класс Constants.cs или что-то в этом роде.
Например, если бы я хотел сохранить специфичные для приложения ключи в любом случае. Я мог бы сохранить его и получить из своей веб-конфигурации через пользовательские ключи или использовать его, ссылаясь на константу в моем классе констант.
Когда вы хотите использовать константы поверх ключей конфигурации?
Этот вопрос действительно относится к любому языку, я думаю.
источник
xsd
инструмент для генерации одного из другого) и использовать конфигурацию сXMLSerializer
(в любом случае, наиболее разумный способ обработки XML в C #), так что вы можете проверять заранее, но это все еще немного Работа.Изменение констант требует перестройки приложения в большинстве случаев. Другими словами, константы остаются константами, когда кто-то не имеет доступа к коду.
Таким образом, любая информация, которую конечный пользователь должен предоставить (и должен изменить), должна находиться в файлах конфигурации. Большинству других нужно идти по постоянным. Однако должны быть допустимые значения по умолчанию или обработка исключений ошибок, если файлы конфигурации повреждены.
Элементы, которые не являются частью абстракции объекта (т. Е. Если константы, которые не предназначены для изменения внешними (вызывающими) объектами, скорее всего, будут скрыты и, по сути, означают, что они будут лучше в качестве частных констант, чем конфигурационные файлы.
Когда есть много элементов конфигурации, которые относятся к разным объектам, не связанным друг с другом, и когда такому количеству объектов необходимо извлечь (одинаковые или свои) файлы конфигурации, есть вероятность, что эти вещи должны быть константами.
источник
Простое практическое правило заключается в создании констант, когда вы знаете, что будете работать с фиксированным набором значений, которые, как вы знаете, могут применяться для любого данного контекста без необходимости их изменения; обеспечить внешние конфигурации для всего остального.
Хорошим примером констант было бы, если бы все фигуры, с которыми вы работали, могли быть
SQUARE
илиROUND
. В большинстве языков вы сможете использовать тот факт, что это значение не изменяется со временем, выделив его только один раз и оптимизировав доступ к нему.Внешние конфигурации необходимы, когда вам нужно получить значение динамически, потому что вы не можете заранее предположить значение, с которым будете работать, но это не значит, что вам нужно делать какие-либо компромиссы производительности: для значений конфигурации вы ожидаете в настоящее время, если все сделано правильно, вы платите только один раз за получение их и все равно получаете все преимущества.
источник
Вы также можете просто использовать этот шаблон проектирования: «соглашение о конфигурации».
http://msdn.microsoft.com/en-us/magazine/dd419655.aspx http://en.wikipedia.org/wiki/Convention_over_configuration
источник
Константа по определению - это область памяти для значения, которое не должно изменяться (например, PI).
Я предполагаю, что вы имели в виду «параметр», а не константа
В дополнение к тому, что было сказано, обратите внимание, что предоставление переменных для ввода данных пользователем из файла конфигурации может нанести вред приложению.
По возможности не выставляйте значения в конфигурационном файле, не проверяя их в коде для проверки работоспособности. Кроме того, я предлагаю не размещать параметры бизнес-правил (например, максимальную зарплату и т. Д.) В файлах конфигурации и не использовать константы для них. Такие значения должны храниться в базе данных с соответствующими определениями таблиц, чтобы обеспечить некоторую безопасность при их изменении, и вы можете автоматически создавать версии значений данных (используя сохраненные журналы procs или db). Конечно, это зависит от того, насколько чувствительно ваше приложение.
Если вы когда-либо используете файлы конфигурации для хранения данных, убедитесь, что вы их версии.
источник