Плюси і мінуси AppSettings vs applicationSettings (.NET app.config / Web.config)

При розробці програми .NET Windows Forms у нас є вибір між цими App.configтегами для зберігання наших значень конфігурації. Який з них кращий?

<configuration>

  <!-- Choice 1 -->
  <appSettings>
    <add key="RequestTimeoutInMilliseconds" value="10000"/>
  </appSettings>

  <!-- Choice 2 -->
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" >
        <section name="Project1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <Project1.Properties.Settings>
      <setting name="TABLEA" serializeAs="String">
        <value>TABLEA</value>
      </setting>
    </Project1.Properties.Settings>
  </applicationSettings>

</configuration>

З основним <appSettings>простіше розібратися - просто заштрихуй <add key="...." value="..." />запис, і ти закінчиш.

Недолік є: немає перевірки типів, наприклад , ви не можете з упевненістю припустити , ваш номер , який ви хотіли налаштувати там дійсно поруч - хто - то може поставити рядок в цю настройку ..... просто отримати доступ до нього , як ConfigurationManager["(key)"]і те , що трапилося щоб ви знали, з чим маєте справу.

Крім того, з часом <appSettings>може стати досить заплутаним і безладним, якщо багато частин вашої програми починають поміщати туди речі (пам’ятаєте старий файл windows.ini? :-)).

Якщо ви можете, я вважаю за краще і рекомендую використовувати власні розділи конфігурації - з .NET 2.0, це стало дуже просто, тому ви можете:

• a) Визначте свої параметри конфігурації в коді та встановіть їх безпечність і перевірку
• б) Ви можете чітко відокремити ВАШІ налаштування від усіх інших. І ви можете повторно використовувати свій конфігураційний код!

Існує ряд дійсно хороших статей про вас, щоб демістифікувати систему конфігурації .NET 2.0 у CodeProject:

1. Розгадування таємниць конфігурації .NET 2.0

2. Розшифровка таємниць конфігурації .NET 2.0

3. Розгортки таємниць конфігурації .NET 2.0

Настійно рекомендується! Джон Rista зробив чудову роботу, пояснивши систему конфігурації в .NET 2.0.

Налаштуваннями програми можна керувати за допомогою дизайнера (зазвичай за замовчуванням є файл Settings.settings), тому його легше змінювати, і ви можете отримати доступ до них програмно через клас "Налаштування", де вони виглядають як властивість із сильним типом. Ви також можете встановити додатки та налаштування на рівні користувача, а також налаштування за замовчуванням для відкоту.

Це доступно від .NET 2.0 далі і знецінює інший спосіб зробити це (наскільки я можу сказати).

Більш докладно наводимо за адресою: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

Я використовую шаблон, який я знайшов деякий час назад, де ви використовуєте основні теги xml, але оберніть налаштування в статичний клас конфігурації. Отже - DIY App.Налаштування.

Статичний візерунок налаштування DotNetPearls

Якщо ви зробите це таким чином, ви можете:

• використовувати різні набори значень конфігурацій для різних середовищ (dev, test, prod)
• передбачити розумні значення за замовчуванням для кожного параметра
• контролювати, як визначаються та інстанціюються значення

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

Налаштування:

<add key="machineName" value="Prod" />
<add key="anotherMachineName" value="Test" />
<add key="EnvTypeDefault" value="Dev" />

<add key="RootURLProd" value="http://domain.com/app/" />
<add key="RootURLTest" value="http://test.domain.com/app/" />
<add key="RootURLDev" value="http://localhost/app/" />

<add key="HumanReadableEnvTypeProd" value="" />
<add key="HumanReadableEnvTypeTest" value="Test Mode" />
<add key="HumanReadableEnvTypeDev" value="Development Mode" />

Налаштувати клас:

using System;
using System.Collections.Generic;
using System.Web;
using WebConfig = System.Web.Configuration.WebConfigurationManager;

    public static class Config
    {
        #region Properties

        public static string EnvironmentType { get; private set; }

        public static Uri RootURL { get; private set; }

        public static string HumanReadableEnvType { get; private set; }

        #endregion

        #region CTOR

        /// <summary>
        /// Initializes all settings when the app spins up
        /// </summary>
        static Config()
        {
            // Init all settings here to prevent repeated NameValueCollection lookups
            // Can increase performance on high volume apps

            EnvironmentType =
                WebConfig.AppSettings[System.Environment.MachineName] ??
                "Dev";

            RootURL =
                new Uri(WebConfig.AppSettings["RootURL" + EnvironmentType]);

            HumanReadableEnvType =
                WebConfig.AppSettings["HumanReadableEnvType" + Config.EnvironmentType] ??
                string.Empty;
        }

        #endregion
    }

Щоб зрозуміти плюси і мінуси налаштувань app.config, пропоную переглянути технічні деталі обох. Я включив посилання, де ви можете знайти вихідний код для обробки, описуючи додаткові технічні деталі нижче.

Дозвольте коротко підсумувати те, що я розпізнав, коли працював з ними ( зверніть увагу: те саме стосується web.configфайлу веб-сайту / веб-програми):

applicationSettings в .NET
(натисніть вище, щоб переглянути вихідний код та технічні деталі)

Плюси

• Вони дозволяють зберігати набрані дані, включаючи типи об’єктів (через serializeAsвластивість)

• Вони мають область користувача та програми, що дозволяє зберігати значення за замовчуванням

• Вони підтримуються в розділі конфігурації Visual Studio

• Довгі рядки та / або дані із спеціальними символами дуже добре підтримуються (наприклад, вбудовані рядки JSON, що містять подвійні лапки)

Мінуси

• Налаштування користувача зберігаються в іншому місці в профілі користувача (із криптованою доріжкою), їх важко очистити

• Налаштування області застосування доступні лише для читання під час виконання програми (під час виконання можуть бути змінені лише налаштування обсягу користувача)

• Код методів читання / запису, створений дизайнером налаштувань Visual Studio, не наданий безпосередньо сторонніми інструментами (див. Посилання вище для вирішення способу вирішення)

AppSettings в .NET
Update: AppSettings в .NET Core
(натисніть вище, щоб переглянути вихідний код та технічні деталі)

Плюси

• "Легкі", тобто прості в обробці

• Читайте та записуйте доступ під час виконання програми

• Вони можуть легко редагуватись адміністраторами в
  Менеджері інформаційних служб Інтернету (IIS)
  ^{(Перегляд функцій -> Налаштування додатків. Зверніть увагу, що назва цього значка вводить в оману, оскільки він може обробляти лише AppSettings, а не ApplicationSettings)}

Мінуси

• Підтримуйте лише рядкові дані; довжина рядка та спеціальні символи обмежені

• Вони не мають сфери роботи користувача

• Вони не підтримують значення за замовчуванням

• Не підтримуються безпосередньо в розділі конфігурації Visual Studio

Мені подобається працювати з більш простою версією для зберігання та доступу до окремих значень.

<appSettings>
    <add key="MyConfigKey" value="true"/>
</appSettings>

Я написав клас утиліти для доступу до значень типовим способом, який дозволяє використовувати значення за замовчуванням. Якщо параметри за замовчуванням не надаються, надаються корисні повідомлення про виключення.

Ви можете переглянути / завантажити клас тут:

http://www.drewnoakes.com/code/util/app-settings-util/