Коли використовувати константи проти налаштування файлів для підтримки конфігурації

Я часто борюся сам над тим, чи потрібно класти певні ключі в моєму 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).

Я припускаю, що ви мали на увазі "параметр", а не константу

На додаток до сказаного, зауважте, що виставлення змінних вводу користувача з конфігураційного файлу може завдати шкоди програмі.

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

Якщо ви коли-небудь використовуєте конфігураційні файли для зберігання даних, обов’язково їх версію.