AppSettings와 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) 코드에서 구성 설정을 정의하고 형식이 안전하고 확인되도록합니다.
• b) 귀하는 깨끗하게 분리 할 수 있습니다 당신의 다른 사람의에서 설정. 구성 코드도 재사용 할 수 있습니다!

CodeProject의 .NET 2.0 구성 시스템을 이해하기위한 일련의 유용한 기사가 있습니다.

1. .NET 2.0 구성의 미스터리 해결

2. .NET 2.0 구성의 미스터리 디코딩

3. .NET 2.0 구성의 미스터리 크래킹

추천! Jon Rista는 .NET 2.0의 구성 시스템을 잘 설명했습니다.

응용 프로그램 설정은 디자이너 (일반적으로 기본적으로 Settings.settings 파일이 있음)에서 제어 할 수 있으므로 수정하기 쉬우 며 강력한 형식의 속성처럼 보이는 Settings 클래스를 통해 프로그래밍 방식으로 액세스 할 수 있습니다. 롤백을위한 기본 설정뿐만 아니라 응용 프로그램 및 사용자 수준 설정을 가질 수도 있습니다.

이것은 .NET 2.0 이상에서 사용할 수 있으며 다른 방법으로 사용하지 않습니다 (알 수있는 한).

자세한 내용은 msdn.microsoft.com/en-us/library/k4s6c3a0.aspx를 참조하십시오.

기본 xml 태그를 사용하지만 정적 구성 클래스의 설정을 래핑하는 패턴을 사용하고 있습니다. 따라서 DIY App.Settings.

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 웹 사이트 / 웹 응용 프로그램 파일 에도 동일하게 적용됩니다 ).

.NET의 applicationSettings
(소스 코드 및 기술 세부 사항을 보려면 위의 클릭)

찬성

• serializeAs속성을 통해 객체 유형을 포함하여 유형이 지정된 데이터를 저장할 수 있습니다.

• 사용자 및 응용 프로그램 범위가 있으므로 기본값을 저장할 수 있습니다

• Visual Studio의 구성 섹션에서 지원됩니다.

• 긴 문자열 및 / 또는 특수 문자가있는 데이터는 매우 잘 지원됩니다 (예 : 큰 따옴표가 포함 된 임베드 된 JSON 문자열)

단점

• 사용자 설정은 사용자 프로필의 다른 위치 (암호 적 경로 포함)에 저장되며 정리하기가 어려울 수 있습니다

• 응용 프로그램 범위 설정은 응용 프로그램을 실행하는 동안 읽기 전용입니다 (런타임 동안 사용자 범위 설정 만 변경할 수 있음)

• 타사 도구에서 직접 제공하지 않고 Visual Studio의 설정 디자이너가 작성한 읽기 / 쓰기 방법 코드 (해결 방법은 위의 링크 참조)

.NET
업데이트의 AppSettings : .NET Core의 AppSettings
(소스 코드 및 기술 세부 정보를 보려면 위의 클릭)

찬성

• "가벼운", 즉 다루기 쉬움

• 응용 프로그램 실행 중 읽기 및 쓰기 액세스

• 
  인터넷 정보 서비스 (IIS) 관리자의 관리자가 쉽게 편집 할 수 있습니다
  ^{(기능보기-> 응용 프로그램 설정, 응용 프로그램 설정이 아닌 응용 프로그램 설정 만 처리 할 수 ​​있기 때문에 아이콘 이름이 잘못되었습니다).}

단점

• 문자열 데이터 만 지원하십시오. 문자열 길이와 특수 문자는 제한되어 있습니다

• 그들은 사용자 범위가 없습니다

• 그들은 기본값을 지원하지 않습니다

• Visual Studio의 구성 섹션에서 직접 지원되지 않습니다

단일 값을 저장하고 액세스하기 위해 더 간단한 버전으로 작업하는 것을 좋아합니다.

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

기본값을 허용하는 안전한 형식으로 값에 액세스하는 유틸리티 클래스를 작성했습니다. 기본값이 제공되지 않으면 유용한 예외 메시지가 제공됩니다.

수업을 보거나 다운로드 할 수 있습니다 :

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