.net에서 어떤 구성 방법을 선호하시나요?왜?[닫은]

StackOverflow https://stackoverflow.com/questions/117407

  •  02-07-2019
  •  | 
  •  

문제

  • App.config를 사용할 수 있습니다.하지만 키/값 쌍만 지원합니다.
  • .Net 구성, 구성 섹션을 사용할 수 있습니다.하지만 정말 복잡할 수 있습니다.
  • Xml Serialization/Deserialization을 직접 사용할 수 있습니다.당신의 수업-당신의 방식.
  • 다른 방법을 사용할 수 있습니다.그들은 무엇이 될 수 있나요?...

다음 중 어떤 방법이나 다른 방법(있는 경우)을 선호합니까?왜?

도움이 되었습니까?

해결책

키 값 쌍이 충분하지 않은 경우 사용하기 복잡하지 않은 구성 섹션을 사용합니다(복잡한 섹션이 필요하지 않은 경우).

사용자 정의 섹션을 정의하십시오.

        public class CustomSection : ConfigurationSection
        {
            [ConfigurationProperty("LastName", IsRequired = true,
            DefaultValue = "TEST")]
            public String LastName
            {
                get { return (String)base["LastName"]; }
                set { base["LastName"] = value; }
            }

            [ConfigurationProperty("FirstName", IsRequired = true, DefaultValue =
            "TEST")]
            public String FirstName
            {
                get { return (String)base["FirstName"]; }
                set { base["FirstName"] = value; }
            }

            public CustomSection()
            {

            }
        }

섹션을 프로그래밍 방식으로 생성합니다(아직 존재하지 않는 경우).

           // Create a custom section.
            static void CreateSection()
            {
                try
                {

                    CustomSection customSection;

                    // Get the current configuration file.
                    System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(@"ConfigurationTest.exe");

                    // Create the section entry  
                    // in the <configSections> and the 
                    // related target section in <configuration>.
                    if (config.Sections["CustomSection"] == null)
                    {
                        customSection = new CustomSection();
                        config.Sections.Add("CustomSection", customSection);
                        customSection.SectionInformation.ForceSave = true;
                        config.Save(ConfigurationSaveMode.Full);
                    }
                }
                catch (ConfigurationErrorsException err)
                {
                    //manage exception - give feedback or whatever
                }

            }

다음 CustomSection 정의와 실제 CustomSection이 생성됩니다.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="CustomSection" type="ConfigurationTest.CustomSection, ConfigurationTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" allowLocation="true" allowDefinition="Everywhere" allowExeDefinition="MachineToApplication" overrideModeDefault="Allow" restartOnExternalChanges="true" requirePermission="true" />
  </configSections>
  <CustomSection LastName="TEST" FirstName="TEST" />
</configuration>

이제 섹션 속성을 검색하세요.

    CustomSection section = (CustomSection)ConfigurationManager.GetSection("CustomSection");
    string lastName = section.LastName;
    string firstName = section.FirstName;

다른 팁

문제를 해결할 수 있다면 App.Config를 사용하겠습니다. 그러나 더 복잡한 것이 필요한 경우에는 사용자 정의 구성 섹션을 사용합니다.예, 처음부터 이해하는 것이 힘들지만, 통일된 구성 소스와 모든 설정에 대한 친숙한 구성은 시간을 투자할 가치가 있다고 생각합니다.

구성을 데이터베이스에 넣으십시오.둘 이상의 컴퓨터(예: 클라이언트-서버 앱)에서 앱을 실행하는 경우 모든 컴퓨터별 구성 시스템은 PITA입니다.단일 구성 영역이 구성을 배치하는 가장 좋은 방법입니다.그것을 관리하기 위한 GUI를 작성하면 매우 행복해질 것입니다.

app.config 파일을 200개의 클라이언트 상자에 롤아웃합니다..재미가 없습니다. 특히 누군가를 놓치면 더욱 그렇습니다.

저는 과거에 네트워크/시스템 관리자였으며 지금은 데이터베이스 애플리케이션용 내부 유틸리티를 개발하고 있습니다.내가 찾은 것은 다음과 같습니다.

단순 비중첩 구성 파일은 리소스에 많이 액세스하는 위치를 변경하지 않는 애플리케이션에 가장 적합합니다.

더 복잡한 것은 관리 UI를 사용하여 데이터베이스에 들어가야 합니다.이는 일반 비즈니스 사용자에게만 적용됩니다.데이터베이스 손상이 걱정된다면 복잡한 구성 파일 접근 방식을 사용하십시오.파일은 데이터베이스보다 손상되는 경향이 적습니다.

이제 사용자가 다른 개발자인 경우 구성을 저장하는 데 사용할 항목에 대해 훨씬 더 많은 유연성을 갖게 됩니다.

내가 찾은 NameValueCollectionHandler 가장 쉽고 최고이며 일반적으로 configSource 속성을 통해 외부 구성 파일에 연결합니다.

구성 파일에 절대 최소 구성을 넣으려고 합니다. 대부분은 배포 환경(예: 알려진 경우 컴퓨터 이름 또는 IP 주소)을 자체 인식하는 응용 프로그램을 사용하여 코드로 구성됩니다.물론 이를 위해서는 환경에 대한 훨씬 더 많은 사전 계획과 지식이 필요하지만 배포 시에는 훨씬 덜 골칫거리입니다.

저는 각 환경(dev/qa/prod)에 대해 서로 다른 구성 파일이 사용되는 사용자 정의 xml 구성 파일을 사용합니다.구성 파일은 서비스에 대한 호스트/포트 구성과 같은 항목으로 동적으로 인스턴스화되는 템플릿입니다. 이는 템플릿 인스턴스화 코드로 처리할 수 있으므로 다중 환경 및 장애 조치를 매우 쉽게 만듭니다.

물론 구성이 거의 없고 여러 환경에 관심이 없다면 app.config가 더 표준적이며 아마도 가장 좋은 방법일 것입니다.

키/값 구성은 간단한 구성 파일에 꽤 잘 작동합니다.파일이 커지기 시작하고 유지 관리가 어려워지면 문제가 됩니다.우리는 구성 파일을 "공통" 및 "특정" 애플리케이션 구성으로 분할하기 시작했습니다.파일 액세스는 앱에 투명합니다. "공통" 값은 대부분의 경우 동일하지만 "특정" 값은 배포된 모든 애플리케이션마다 다릅니다.

사용자 정의 XML 구성 파일을 사용합니다.각 설정에는 키, 값 및 유형이 있습니다.

여기에는 모든 설정을 포함하는 하나의 기본 섹션과 특정 환경(개발, 준비, 라이브)에 대한 설정 재정의를 포함하는 추가 섹션이 있습니다.배포할 때 파일의 섹션을 바꿀 필요가 없습니다.특정 설정이나 모든 설정을 포함하는 사전을 얻기 위해 호출할 수 있는 작은 래퍼가 있습니다.

나는 최근에 T4 템플릿 구성 파일을 읽고 정적이며 강력한 형식의 설정 클래스를 생성합니다.그것은 엄청난 시간 절약이었습니다.

나는 대부분의 구성을 IoC 컨테이너에 보관합니다.스프링.넷.

.NET 3.0을 사용할 수 있는 경우 XamlReader/XamlWriter가 설정을 저장하는 데 매우 편리하다고 생각합니다.다음과 같은 경우 모든 .NET 개체를 XAML에 쓰거나 읽을 수 있습니다.

  • 객체에 매개변수 없는 생성자가 있습니다.
  • 읽기/쓰기 속성에는 공개 getter 및 setter가 있습니다.

어떤 속성으로도 설정 개체를 장식할 필요가 없다는 점이 특히 좋습니다.

dataset.WriteXML()/dataset.ReadXML()은 app.config가 더 이상 잘라내지 않을 때 꽤 잘 작동합니다.

대부분 나는 이 구성 파일을 읽고 쓰기 위해 사용자 정의 XML 파일과 Xml 직렬화 방법을 사용하는 것을 선호합니다...키/값 쌍으로 제한되지 않으며 구현이 복잡하지 않습니다.

나는 호출 어셈블리와 연관된 ".settings" 파일에서 구성 데이터를 반환하는 나만의 특수 클래스를 굴리는 행운을 누렸습니다.파일은 XML이며 설정 클래스는 이를 XDocument로 공개적으로 노출합니다.또한 이 설정 클래스의 인덱서는 /settings/setting 노드에서 요소 값을 반환합니다.

설정에 대한 키/값 쌍 액세스만 필요한 간단한 애플리케이션에 적합하고, 자체 구조를 정의하고 System.Xml.Linq를 사용하여 XML 문서를 쿼리해야 하는 복잡한 설정에 적합합니다.

직접 롤링하는 것의 또 다른 이점은 FileSystemWatcher 및 콜백 작업 유형을 사용하여 런타임 시 파일이 변경될 때 자동으로 메서드를 실행할 수 있다는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top