응용 프로그램 설정을 저장하는 가장 좋은 방법


17

Windows에서 기본 방법은 레지스트리입니다. 이를 통해 시스템 전체 및 사용자 별 설정을 차별화 할 수 있습니다.

유닉스에서는 시스템 전체 설정을 위해 / etc 폴더에 텍스트 파일을 사용해야합니다 (사용자 별 설정 규칙은 무엇입니까?).

많은 새로운 프로그램 (특히 이식 가능하도록 설계된 프로그램)은 XML 파일을 사용합니다.

  • BLOB 이외의 설정을 저장하는 가장 좋은 방법 (및 위치)은 무엇입니까?
  • 각 시스템 기본값을 따라야합니까 아니면 통합 솔루션이 있어야합니까?
  • 가장 좋은 휴대용 방법은 무엇입니까?

무엇에 대해 매우 구체적으로하시기 바랍니다 당신이 "최고"를 의미한다.

3
@ Thorbjørn : 최고의 최고 조정 \ ˈbest \ 최상
Wizard79

3
StackExchange 사이트에서 "최고"의 다양한 의미에 놀랄 것입니다.

답변:


23

BLOB 이외의 설정을 저장하는 가장 좋은 방법 (및 위치)은 무엇입니까?

Windows에서는 레지스트리를 사용하는 것이 허용되는 것 같습니다. 제 생각에는 레지스트리가 잘못 개발 된 시스템이므로 Users\Username\AppData디렉토리 의 간단한 텍스트 파일을 선호해야합니다. 이는 백업하기 쉽고 사용자가 수정하기에 덜 위험하며 정리하기가 쉽습니다.

Linux 및 대부분의 Unix에서 기본 위치는 /home/user/.config/appname사용자 별 설정 및 /etc/전역 (시스템 전체) 설정입니다. 사용자 설정에 대해 덜 선호되는 (하지만 수용 가능한) 위치는 ~/.appname이지만 일반적으로 선호하지 않습니다. 이러한 파일은 사용자가 편집 할 수 있어야하며 사람이 읽을 수있는 형식이 항상 선호됩니다.

필자는 XML이 데이터가 아닌 데이터를 저장하기에 적합한 형식이라는 데 대부분의 사람들의 의견에 동의하지 않습니다. 제 생각에는 일반적으로 매우 작은 구조화 된 데이터 조각에 대한 과장되고 지나치게 복잡한 형식입니다. YAML, JSON, ASN.1, 이름 = 값 쌍 또는 유사한 형식의 파일을 선호합니다. 구문이 너무 많으면 사용자가 파일을 엉망으로 만들거나 파일을 유효하지 않은 형식으로 남기기가 너무 쉽습니다.

각 시스템 기본값을 따라야합니까 아니면 통합 솔루션이 있어야합니까?

그것은 전적으로 당신에게 달려 있지만, 몇 가지 사항을 명심하십시오.

  • * nix와 같은 플랫폼에는 쓰기 가능한 위치에 대한 엄격한 제한이 있습니다. Windows보다 더 엄격합니다. 그래서:
    • 무엇이든 써야하는 유일한 위치는 사용자의 홈 디렉토리입니다.
    • 하지 않는 응용 프로그램 시스템 서비스입니다; 이 경우 모든 가변 데이터 파일을로 작성해야합니다 /var/. Nonmutable 데이터 파일에서 응용 프로그램 디렉토리에 보관해야 /usr/share/하거나 /usr/local/share/또는/opt/
    • 의 구성 파일 /etc/해야 결코 응용 프로그램에 기록되지는 그들에게 쓰기 권한이있는 경우에도, 실행되는 경우. 기본 비헤이비어 /etc/의 리포지토리 여야하며 다른 것은 없습니다.
    • 응용 프로그램에 대한 계획은 세 곳 중 하나에 설치합니다 : /usr/local/, /opt/appname또는 /home/username/appname.
    • Blob은 변경 될 경우 다른 구성 파일과 함께 저장해야합니다. 이다 일반적으로 바람직 SQLite는 나 버클리 DB 같은이 (각 명령 줄 도구가 있기 때문에) 선호하지만,되지 않도록, 사용자가 편집 가능한 형식을 사용하는 것이 필요합니다.
  • Windows에서 응용 프로그램은 사용자 디렉토리에만 작성해야합니다. 데이터 파일의 표준화 된 위치는 Users\User\AppData입니다. 다른 곳은 용납되지 않는 것 같습니다.
  • Mac OS X에서는 응용 프로그램 설정이 ~/Library/Preferences다른 모든 응용 프로그램의 plist 파일과 함께 저장되어야 합니다. plist선호하는 형식으로 보이지만 Apple 지침을 다시 확인하고 싶을 것입니다.

가장 좋은 휴대용 방법은 무엇입니까?

솔직히 "최고"는 없습니다. 플랫폼 별 제한 사항과 기대 사항 만 있습니다. 더 많은 코드를 작성하더라도 플랫폼 별 수단을 사용하는 것이 좋습니다.


1
나는 마이크로 소프트가 레지스트리를 몇 년 동안 사용하지 말아 왔다고 생각한다. 언급했듯이 AppData에 쓰는 것이 좋습니다. .NET (아마도 Windows API?)에는 올바른 경로를 반환하는 메소드도 있습니다.
MetalMikester

환경 변수도 있습니다 :%APPDATA%
greyfade

@MetalMikester-그렇습니다. 도메인 환경에 대한 로밍 프로필에서도 AppData가 지원됩니다.
JBR 윌킨슨

설정! = 구성
Yousha Aleayoub

> In my opinion, the registry was a poorly-devised system, and instead a simple text file in the Users\Username\AppData directory should be preferred. @greyfade-오랜 Windows API 개발자 인 Raymond Chen은이 문제를 해결하고 레지스트리를 통해 텍스트 파일을 사용하는 것이 더 나은 디자인 패턴이 아닌 이유를 설명합니다. INI 파일이 레지스트리를 위해 더 이상 사용되지 않는 이유
Mick

8

Windows에서는을 사용하십시오 %APPDATA%\appname. * NIX에서을 사용하십시오 ~/.appname. 사용자의 홈 디렉토리가 기본값과 다를 수 있으므로 (예 : 네트워크에있을 수 있음) 두 플랫폼에서 고정 디렉토리 이름을 사용하지 마십시오.

형식은 자신이 가장 잘 생각하는 것을 사용하십시오. 그것은 당신의 응용 프로그램의 맥락에서 당신 만이 수 있는 결정입니다 . "표준"방법이 특정 프로그램에 가장 적합한 방법이 아닌 경우, "표준"방법을 사용하는 것은 불필요하며 불가피합니다.

예를 들어, 응용 프로그램이 이미 XML / JSON을 다른 용도로 사용하는 경우 XML / JSON이 사용자 데이터 / 구성을 저장하는 좋은 방법 일 수 있습니다. 그러나 간단한 구성 파일 인 경우 종속성을 도입하여 앱에 팽창을 추가하는 이유는 무엇입니까? 이 경우 간단한 텍스트 파일을 var: value\n줄 대신 사용하는 것이 가장 좋습니다.

편집 : "최고의"휴대용 방법은 없습니다. OS는 이에 대해 매우 다른 규칙을 사용하기 때문입니다. 피의 정당한 이유없이 OS 표준을 어 기지 마십시오.

EDIT2 :/etc 또는 에서 시스템 전체 설정을하는 HKEY_LOCAL_MACHINE경우 설정이 실제로 전역 적인지 자문하십시오 . 그런 다음 5 분 정도 기다렸다가 다시 물어보십시오. 대답이 여전히 그렇다면 반드시 전역 설정을 구성하십시오. 일반 사용자가 쓰기 권한이없는, 기억 /etc또는 HKEY_LOCAL_MACHINE당신이 당신의 응용 프로그램을 설치할 수 없습니다 관리자 권한이없는 누군가를 보장하고, 이렇게.


첫 번째 단락은 Path.Combine 또는 이와 유사한 것을 사용하여 상대 루트 위치를 % APPDATA % 또는 ~으로 설정하고 코드가 나머지를 수행하게합니다 .EDIT2의 경우 실제로 알려진 크로스 플랫폼 솔루션이 없습니다. 의. 어쩌면 그 목적을 위해 크로스 플랫폼 구성 라이브러리를 쓴 사람들이, 적어도 ... 멋진 생각이 될 것입니다
타마라 Wijsman

1
@ TomWij : 확실히 모든 유능한 개발자는 어디서나 리터럴을 사용할 필요가 없다는 것을 알 수 있어야합니다.). 그것이 변수에 대한 것입니다.
Chinmay Kanchi

1
~/.config/applicaton* nix에서 점점 선호되는 위치가되었습니다.
greyfade

@ greyfade : 나는 실제로 이것을 깨닫지 못했지만 당신이 옳습니다. 내 컴퓨터에서 구성 데이터를 저장하는 응용 프로그램의 약 1/4이에 저장 ~됩니다 ~/.config/appname.
Chinmay Kanchi

많은 앱이 Windows에서 ~ / .appname을 사용하고 (문서가 아닌 사용자 프로필 디렉토리와 동일) 매우 성가시다. 그 폴더는 자신을 숨기지 않습니다!
Alan Pearce

3

나는 시도하고 레지스트리 닿지 않는 곳에 보관, 그것은되는 방법 을 통해 사용. 모두가 그러기를 바랍니다.

XML 구성 파일이나 bin 파일 또는 로컬 데이터베이스 (SQLite)를 유지하는 것이 좋습니다.


레지스트리에서 제외하려면 +1하십시오. 지금은 찾을 수 없지만 MS의 누군가가 레지스트리가 실수라고 인정했다는 것을 기억하는 것 같습니다.
Chinmay Kanchi

1
XML 부분을 제외하고 동의하십시오. 간단한 설정 요구 사항에는 복잡한 ii (또는 간단한 텍스트 파일)를 사용하고 복잡한 앱에는 SQLite를 사용합니다.
Codism

지금 막 인정하고 있습니까? 나는 1995 년에 당신에게 그것을 다시 말할 수있었습니다! Mac OS Classic은 설정 정보를 저장할 중앙 위치를 제공하는 기본 설정 폴더를 제공하며 각 앱은 자체 파일로 저장됩니다. 레지스트리를 처음 보았을 때, "Microsoft가 모든 달걀을 한 바구니에 담지 않은 것을 들어 본 적이 있습니까?!"
메이슨 휠러

1
파일 확장자 등록과 같은 OS 설정을 넣을 수있는 장소라고 생각합니다. 그러나 Microsoft가이 파일을 읽기 전용 API로 게시 한 경우에는 해당 문서를 고소했을 수 있으며 어쨌든 쓰기 가능해야합니다.
µBio September

@Chinmay, @Mason, 레지스트리는 단순히 구성 데이터를 저장하는 것 이상으로 FAR을 수행하기 때문에 실수가 아닙니다 (그룹 정책, 도메인, 복제 참조). 실수는 마이크로 소프트가 개발자들에게 그것을 던진 방법과 그것을 사용하는 방법에 대한 좋은 표준이 없다는 것입니다. 결국 앱 데이터의 덤핑 그라운드가되었습니다.
Matt Olenik

3

내 대답은 Chinmay Kanchi의 답변 과 BioBuckyBall의 답변 의 조합입니다 .

간단한 구성을위한 XML / Json, 복잡하고 큰 구성을위한 SQLite는 구성이 사용자 종속적 인 경우 기본 OS 응용 프로그램 폴더 또는 기본 OS 사용자 폴더에 보관됩니다. 둘 다 사용할 수 있습니다.


2

Windows에서는 응용 프로그램 설정을 AppData폴더에 유지 합니다


1

사용자 설정은 일반적으로

/home/<user>/.<application> 

예를 들어 irssi 설정은 /home//.irssi/config입니다.


그러나 이것은 유닉스 관습입니다. Windows는 어떻습니까? 그리고 리눅스에서 하위 디렉토리로 사용자 홈 디렉토리를 넘치지 않습니까? 왜 안돼 /home/<user>/etc/application?
Wizard79

@Lorenzo : 사용자의 홈 디렉토리를 넘치게하는 것은 거의 문제가되지 않습니다.
Chinmay Kanchi

1
~/.config/application통합 된 상태를 유지 하기 위해 구성 설정이 점차 이동 하고 있습니다. 나는이 운동에 동의하는 경향이있다.
greyfade

1
@Lorenzo : 이것은 설정 파일을 저장하는 Windows 규약과 정확히 동일합니다 AppData.
greyfade

1
@Chris : 안 돼요! :-)
Wizard79

1

선호하는 플랫폼 별 메커니즘을 사용하는 것이 가장 좋습니다. 예를 들어, OS X에서 선호되는 메커니즘은 ~ / Library / Preferences에 등록 정보 목록을 배치하는 것이며 Cocoa API는 설정을 저장하고 검색하기위한 인터페이스가 매우 간단합니다.

앱이 크로스 플랫폼 인 경우 클래스 또는 기타로 추상화 할 수 있습니다.


0

내가 레지스트리에 쓰는 유일한 것은 앱의 위치이므로 설치 프로그램과 업데이터가 쉽게 찾을 수 있습니다. 다른 모든 것은 / AppData / Company / App의 파일에 저장됩니다


-2

Java 응용 프로그램의 경우 gson 이 좋은 선택 이라고 생각 합니다. 설정 객체를 만들고 gson을 사용하여 JSON으로 변환하거나 그 반대로 변환하십시오. 직렬화 된 얼룩 대신 사람이 읽을 수있는 장점이 있습니다.

편집 : 좋아, 그렇게 일반적인 것은 아닙니다 ...


당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.