응용 프로그램 설정 파일
자, 여기서 성전을 시작하고 싶지는 않지만, 애플리케이션 구성 파일 처리 방식을 통합하는 과정에서 최선의 방법을 결정하는 데 어려움을 겪고 있습니다.현재 배포되는 모든 애플리케이션은 속성 파일(ini 스타일), XML 또는 JSON(현재 내부 사용만 가능!)에 관계없이 자체 애드혹 구성 파일을 사용하고 있습니다.
현재 코드 대부분은 Java이기 때문에 Apache Commons Config를 살펴보았지만 상당히 상세하다는 것을 알게 되었습니다.XMLBean도 살펴보았지만 많은 문제가 있는 것 같습니다.또, 형식으로서 XML을 강요당하고 있는 것 같은 느낌도 듭니다만, 클라이언트나 동료는 다른 것을 시도하는 것에 대해 염려하고 있습니다.고객 입장에서는 XML에 대해 들어본 적이 있지만, 결국 업무에 적합한 툴을 사용해야 하는 것은 아닐까요?
요즘 사람들이 생산 시스템에서 사용하는 형식과 라이브러리는 어떤 것들이죠, 앵글 괄호 세금을 회피하려는 사람이 또 있나요?
편집:Linux, Windows, Solaris 등의 크로스 플랫폼 솔루션이 필요합니다.또한 구성 파일과의 인터페이스에 사용할 라이브러리를 선택하는 것도 포맷 선택과 마찬가지로 중요합니다.
XML에 비해 읽기 쉬운 Configuration파일을 작성하기 위한 간단한 이유 때문에 YAML을 사용합니다.
XML:
<user id="babooey" on="cpu1">
<firstname>Bob</firstname>
<lastname>Abooey</lastname>
<department>adv</department>
<cell>555-1212</cell>
<address password="xxxx">ahunter@example1.com</address>
<address password="xxxx">babooey@example2.com</address>
</user>
YAML:
babooey:
computer : cpu1
firstname: Bob
lastname: Abooey
cell: 555-1212
addresses:
- address: babooey@example1.com
password: xxxx
- address: babooey@example2.com
password: xxxx
http://www.kuro5hin.org/story/2004/10/29/14225/062 의 예를 이 페이지에서 발췌했습니다.
첫 번째: 이것은 매우 큰 토론의 문제이며, 간단한 Q+A가 아닙니다.
지금 내가 가장 좋아하는 건 루아를 단순히 포함시키는 거야 왜냐하면
- width=height*(1+1/3) 등의 허용 가능
- 커스텀 기능을 사용할 수 있다
- 다른 건 금지할 수 있어요.(예를 들어 Python(피클 포함)에서는 불가능합니다.)
- 어쨌든 스크립팅 언어는 프로젝트의 다른 곳에 있었으면 좋겠어요.
데이터가 많은 경우에는 sqlite3를 사용하는 것도 좋습니다.그것은, 데이터 청구가 옳기 때문입니다.
- 작은.
- 빠른.
- 믿을 수 있는.
3개 중 하나를 선택하세요.
여기에 추가하고 싶은 것은,
- 백업은 간단합니다.(db 파일을 복사하기만 하면 됩니다).
- 다른 DB, ODBC 등으로 전환하기 쉽습니다.(그것은 가짜 줄에서 나온 것보다)
하지만 다시 말하지만, 이것은 더 큰 문제입니다.이에 대한 "큰" 답변에는 다음과 같은 기능 매트릭스 또는 상황 목록이 포함될 수 있습니다.
데이터 양 또는 짧은 런타임
- 대량의 데이터의 경우 DB와 같은 효율적인 스토리지가 필요할 수 있습니다.
- 단기간(종종)의 경우 많은 파싱을 수행할 필요가 없으며 mmap: 직접 입력할 수 있는 것을 고려할 수 있습니다.
이 설정은 무엇에 관련되어 있습니까?
- ★★★★★★★★★★★★★★★★★★:
- /etc의 YAML을 좋아합니다.그것은 창문에 재실장되어 있습니까?
- ★★★★★★★★★★★★★★★★★★:
- 사용자가 텍스트 편집기를 사용하여 설정을 편집할 수 있도록 허용합니까?
- 중앙 집중식으로 관리해야 합니까?레지스트리 / gconf / remote db?
- 사용자가 여러 개의 다른 프로파일을 가질 수 있습니까?
- ★★★★★★★★★★★★★★★★★★:
- 프로젝트 디렉터리에 있는 파일입니까? (버전 제어는 보통 이 모델을 따릅니다...)
복잡성
- 플랫 값이 몇 개밖에 없나요?YAML을 고려합니다.
- 데이터가 중첩되어 있습니까, 아니면 어떤 식으로든 종속되어 있습니까? (이것이 흥미로운 부분입니다.)
- 어떤 형태로든 스크립팅을 허용하는 것이 바람직한 기능일까요?
- 템플릿은 구성 파일의 한 종류로 볼 수 있습니다.
XML XML XML 구성 파일입니다.퍼포먼스 부하가 높은 상황에서 오브젝트를 시리얼화하지 않으면 "각 괄호세"가 부과되지 않습니다.
컨피규레이션파일은 기계에서 읽을 수 있을 뿐만 아니라 사람이 읽을 수 있고 사람이 이해할 수 있어야 합니다.XML은 두 가지 사이에서 적절한 타협입니다.
만약 당신의 가게가 그 새로운 XML 기술을 두려워하는 사람들을 가지고 있다면, 나는 당신에게 안쓰럽습니다.
새로운 성전을 일으키지 않고, '각세' 포스트의 정서는 내가 제프에게 크게 동의하지 않는 부분이다.XML에는 아무런 문제가 없습니다. XML은 사람이 읽을 수 있습니다(YAML, JSON 또는 INI 파일만큼). 그러나 XML의 목적은 기계에서 읽는 것입니다.대부분의 언어/프레임워크 조합에는 XML 파서가 무료로 제공되므로 XML을 선택하는 것이 좋습니다.
또, Visual Studio 와 같은 좋은 IDE 를 사용하고 있는 경우, XML 에 스키마가 부속되어 있는 경우는, 스키마를 VS 에 건네주면, 마법처럼 인텔리센스를 얻을 수 있습니다(예를 들면, NHibernate 용으로 취득할 수 있습니다).
최종적으로는, 실가동시에 이러한 파일을 만지는 빈도를 생각해 둘 필요가 있습니다.아마도 그렇게 자주 만지는 일은 없을 것입니다.
XML에 관한 모든 것을 알 수 있으며, (Tim Bray에서) 왜 그것이 여전히 구성 파일에 유효한 선택인지도 알 수 있습니다.
수신자가 예상치 못한 이상하고 엉뚱한 일을 하고 싶은 범용 데이터를 제공하고 싶은 경우, i18n에 대해 편집증적이고 까다로운 경우, 송신하는 데이터가 구조체보다 문서에 가까운 경우, 데이터의 순서가 중요한 경우, 데이터의 수명이 길 수 있는 경우(예:XML을 사용하는 것이 좋습니다.XML과 XPath의 조합은 확장성이 필요한 데이터 포맷에 최적인 것 같습니다.즉, 관심 있는 내용에 영향을 주지 않는 메시지 포맷이 변경되어도 실패하지 않는 XML 처리 코드를 쓰는 것이 매우 쉽습니다."
@가이
그러나 애플리케이션 구성이 반드시 키/값 쌍만은 아닙니다.tomcat Configuration과 같은 포트에서 리슨하는 포트를 확인합니다.다음은 예를 제시하겠습니다.
<Connector port="80" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />
<Connector port="8009"
enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
커넥터는 개수에 관계없이 사용할 수 있습니다.파일에서 더 많은 것을 정의하면 더 많은 커넥터가 존재합니다.더 이상 정의하지 말고 더 이상 존재하지도 마세요.일반적인 오래된 키/값 쌍으로는 이 작업을 수행할 수 있는 좋은 방법(imho)은 없습니다.
앱의 구성이 간단하다면 INI 파일처럼 사전에 읽혀지는 간단한 것이 좋습니다.다만, 서버 구성등의 보다 복잡한 환경에서는, INI 파일을 관리하는 것이 매우 귀찮아지기 때문에, XML 나 YAML 와 같은 보다 구조적인 것이 좋습니다.모든 것은 문제 세트에 달려 있습니다.
ini 스타일의 설정 파일을 사용하고 있습니다.Nini 라이브러리를 사용하여 관리합니다.Nini는 매우 사용하기 쉽게 만듭니다.니니는 원래 에 대한 것이었다.NET 단, Mono를 사용하여 다른 플랫폼으로 이식되었습니다.
XML, JSON, INI.
을 사용하다
애플리케이션 컨텍스트에서는 추상화 레이어가 중요하다고 생각합니다.
인간의 가독성과 코드로 데이터에 액세스/추출하는 방법 사이에서 적절한 중간 토대가 되는 데이터 구조를 선택할 수 있다면, 귀하는 최고입니다.
주로 XML을 사용하는데, 처음 읽었을 때나 쓴 후에 캐시에 개체로 로드된 구성 파일을 프로그램의 나머지 부분에서 추상화하면 CPU와 디스크 공간 모두에 큰 도움이 되지 않습니다.
파일을 올바르게 구성하기만 하면 읽을 수 있습니다.
또한 모든 플랫폼의 모든 언어가 공통 라이브러리를 통해 XML을 지원합니다.
@헤름스
즉, 소프트웨어가 특정 플랫폼의 설정값을 저장하는 권장 방법을 고수하는 것입니다.
이러한 변경은 권장되는 방법이기도 합니다.프로그램의 설정 메뉴나 시스템 프리프 애플리케이션(시스템 서비스 소프트웨어용)의 설정 패널 등.RegEdit 또는 NotePad를 통해 최종 사용자가 직접 수정할 수 없도록 함...
왜요?
- 최종 사용자(=사용자)는 플랫폼에 익숙합니다.
- 백업용 시스템을 통해 "안전한 설정" 등을 보다 효율적으로 저장할 수 있습니다.
@ninesided
「라이브러리의 선택」에 대해서는, 선택한 라이브러리의 링크(정적 링크)를 실시해, 최종 유저의 머신으로 버전 경합이 발생할 위험을 줄입니다.
컨피규레이션파일이 1회 쓰기, 부트업 시 읽기 전용이고 데이터가 이름 값 쌍의 집합인 경우 개발자가 먼저 작업할 수 있는 것이 최선의 선택입니다.
데이터가 좀 더 복잡하거나 중첩 등이 있는 경우 YAML, XML 또는 SQLite를 사용하는 것이 좋습니다.
부트업 후 네스트된 데이터 및/또는 구성 데이터를 쿼리하는 기능이 필요한 경우 XML 또는 SQLite를 사용합니다.둘 다 구조화/내스트된 데이터에 대해 상당히 우수한 쿼리 언어(XPATH 및 SQL)를 사용합니다.
구성 데이터가 고도로 정규화된 경우(예: 5번째 정규 형식) SQLite를 사용하는 것이 좋습니다. SQL이 고도로 정규화된 데이터를 처리하는 데 더 좋기 때문입니다.
프로그램 조작 중에 구성 데이터 세트에 쓸 계획이라면 SQLite를 사용하는 것이 좋습니다.예를 들어, 다른 컴퓨터에서 구성 데이터를 다운로드하거나 이전 프로그램 실행에서 수집된 데이터를 기반으로 향후 프로그램 실행 결정을 내리는 경우입니다.SQLite는 매우 강력한 데이터 스토리지 엔진을 구현합니다. 이 엔진은 오류로 인해 정전이 발생하거나 프로그램이 일관되지 않은 상태로 중단되는 경우 손상되기 매우 어렵습니다.데이터가 손상되면 필드 지원 비용이 높아집니다.SQLite는 XML 또는 YAML과 관련된 자체 개발 솔루션이나 일반적인 라이브러리보다 훨씬 뛰어난 성능을 발휘합니다.
SQLite에 대한 자세한 내용은 내 페이지를 참조하십시오.
사용하고 있는 경우는, Windows 레지스트리는, 설정을 보존하는 방법이 아닌 것으로 알고 있습니다.NET - 현재 대부분의 응용 프로그램이 시스템을 사용하고 있습니다.설정 [1, 2]이 역시 XML 기반이기 때문에 모든 것이 XML을 사용하여 구성을 수행하는 방향으로 진행되고 있는 것으로 보입니다.
크로스 플랫폼을 유지하려면 텍스트 파일 같은 것을 사용하는 것이 가장 좋은 방법입니다.이 파일의 포맷에 대해서는, 인간이 조작할지를 고려해 주세요.XML은 INI 파일보다 수동 조작에 조금 더 편리한 것 같습니다.파일의 구조가 눈에 띄기 때문입니다.
앵글 브라켓 세금에 대해서는 XML 라이브러리가 추상화 처리를 하고 있기 때문에 자주 걱정하지 않습니다.고려할 수 있는 유일한 시기는 작업할 스토리지 공간이 매우 적고 모든 바이트가 중요한 경우입니다.
[1] 시스템구성 이름 공간 - http://msdn.microsoft.com/en-us/library/system.configuration.aspx
[2] 의 응용 프로그램컨피규레이션파일 사용.NET - http://www.developer.com/net/net/article.php/3396111
속성 파일을 사용하는 이유는 Java가 네이티브로 지원하기 때문입니다.몇 달 전에 Spring Source Application Platform이 JSON을 사용하여 서버를 구성하는 것을 보았습니다.그것은 매우 흥미로워 보입니다.다양한 설정 표기를 비교한 결과, 현시점에서는 XML이 가장 적합하다고 판단했습니다.툴 지원이 뛰어나고 플랫폼에 의존하지 않습니다.
에파텔 코멘트
원래 질문은 사용자의 기본 설정을 저장하는 것이 아니라 관리자가 수행하는 애플리케이션 구성에 대한 질문이었다고 생각합니다.제안하신 내용은 어플리케이션 구성보다 사용자 프리프용으로 더 많은 것 같습니다.또한 사용자가 직접 다룰 수 있는 것은 아닙니다(앱은 UI에서 설정 옵션을 제공하고 나서 파일을 업데이트해야 합니다).사용자가 레지스트리를 보거나 편집할 필요가 없도록 해야 합니다.:)
실제의 질문에 대해서는, XML 의 설정에 익숙해져 있는 사람이 많기 때문에, XML 이면 충분하다고 생각합니다.설정값을 사용하기 쉬운 방법으로 구성하기만 하면 "각 괄호세"는 그다지 나쁘지 않습니다.
여기서 약간 접선적인 면이 있지만, 내 의견은 앱이 처음 시작할 때 설정 파일을 키 값 사전/해시 테이블로 읽어들이고 그 이후로는 항상 이 개체를 통해 액세스해야 속도를 높일 수 있다는 것입니다.일반적으로 키/값 테이블은 문자열에서 문자열로 시작되지만 개체 내의 도우미 함수는 DateTime GetConfigDate(문자열 키) 등의 작업을 수행합니다.
중요한 것은 원하는 포맷을 선택하고 빠르게 탐색하는 것이라고 생각합니다.XML과 JSON은 둘 다 구성에 적합한 형식이며 광범위하게 지원됩니다. 기술적인 구현은 문제의 핵심이 아닙니다.컨피규레이션파일 작업을 쉽게 하는 것이 무엇인지에 관한 것입니다.
JSON을 데이터 전송 포맷으로 많이 사용하고 있기 때문에 어떤 개발 프레임워크에도 쉽게 로드할 수 있습니다.JSON은 XML보다 읽기 쉽기 때문에 각각 매우 자주 수정되는 구성 파일을 사용하여 여러 서비스를 처리할 수 있습니다.
어떤 플랫폼에서 작업하고 있습니까?선호하는 일반적인 방법을 사용해 보는 것을 추천합니다.
- MacOSX - 목록
- Win32 - 레지스트리(또는 새로 개발한 레지스트리)
- Linux/Unix - ~/.apprc (이름값일 수 있음)
언급URL : https://stackoverflow.com/questions/12144/application-configuration-files
'programing' 카테고리의 다른 글
| AngularJs를 통해 브라우저가 캐시를 강제로 클리어합니다. (0) | 2023.03.20 |
|---|---|
| 각도 변환으로 현재 언어 가져오기 (0) | 2023.03.20 |
| Next.js에서의 인증 구현 방법 (0) | 2023.03.20 |
| JPA: 특정 필드만 업데이트 (0) | 2023.03.20 |
| 컴포넌트 상태를 직접 변경할 수 없는 이유는 무엇입니까? (0) | 2023.03.20 |