アプリケーション設定を保存する最良の方法


17

Windowsでは、デフォルトの方法はレジストリです。これにより、システム全体の設定とユーザーごとの設定を区別できます。

Unixでは、システム全体の設定に/ etcフォルダー内のテキストファイルを使用する必要があります(ユーザーごとの設定の規則は何ですか?)。

多くの新しいプログラム(特に、移植用に設計されたプログラム)はXMLファイルを使用します。

  • 非BLOB設定を保存する最良の方法(および場所)は何ですか?
  • 各システムのデフォルトに従うか、統合ソリューションを使用する必要がありますか?
  • そして、最高のポータブルな方法は何ですか?

「ベスト」とどういう意味か、具体的にご説明ください。

3
@Thorbjørn:最高の最高の adj \ ˈ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/。可変でないデータファイルは/usr/share//usr/local/share/または/opt/
    • 構成ファイルは、アプリケーションへの書き込みアクセス権がある場合でも、実行中のアプリケーションによって書き込まれる/etc/べきではありません。デフォルトの動作/etc/のリポジトリであり、他には何もないはずです。
    • 3ヶ所のいずれかにインストールされるアプリケーションのための計画:/usr/local//opt/appname、または/home/username/appname
    • BLOBを変更する場合は、他の構成ファイルと一緒に保存する必要があります。一般的に好ましいのSQLiteまたはBerkeley DBのようなものは、(それぞれのコマンドラインツールがあるため)が好ましいが、されていないので、ユーザが編集可能な形式を使用する必要。
  • Windowsでは、アプリケーションはユーザーディレクトリにのみ書き込む必要があります。データファイルの標準化された場所はUsers\User\AppDataです。他に受け入れられる場所はありません。
  • Mac OS Xでは、アプリケーション設定~/Library/Preferencesは、他のすべてのアプリケーションのplistファイルとともに保存される必要があります。plist推奨される形式のようですが、Appleのガイドラインを再確認してください。

そして、最高のポータブルな方法は何ですか?

正直なところ、「ベスト」というものはありません。プラットフォーム固有の制限と期待のみがあります。私の推奨事項は、コードをさらに記述することを意味する場合でも、プラットフォーム固有の手段に固執することです。


1
マイクロソフトは数年前からレジストリの使用を思いとどまらせてきたと思います。これは良いことです。先ほど述べたように、AppDataへの書き込みが進むべき方法です。.NETには(おそらくWindows APIにもあります)正しいパスを返すメソッドさえあります。
MetalMikester

環境変数もあります:%APPDATA%
greyfade

@MetalMikester-はい、絶対に注目してください。AppDataは、ドメイン環境の移動プロファイルでもサポートされています。
JBRウィルキンソン

設定!= config
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の開発者、レイモンド・チェン、アドレスこの、およびレジストリ上のテキストファイルを使用すると、より良いデザインパターンではない理由を説明する:なぜINIは、レジストリの賛成で廃止予定のファイルされている
ミック・

8

Windowsでは、を使用します%APPDATA%\appname。* NIXの下で、を使用します~/.appname。ユーザーのホームディレクトリはデフォルトと異なる場合があるため(ネットワーク上など)、どちらのプラットフォームでも固定ディレクトリ名を使用しないでください。

形式については、最適と思われるものを使用してください。それは唯一の決定であるあなたが、あなたのアプリケーションのコンテキストで行うことができます。特定のプログラムにとって「標準」の方法が最適でない場合は、「標準」の方法を使用する必要はありません。実際、お勧めできません。

たとえば、アプリケーションが既に他の目的でXML / JSONを使用している場合、XML / JSONはユーザーデータ/構成を保存する良い方法です。しかし、単純な構成ファイルの場合、依存関係を導入してアプリに肥大化を加えるのはなぜですか?その場合、var: value\n代わりに行を含む単純なテキストファイルを使用するのがおそらく最善です。

編集: OSはこれに非常に異なる規則を使用しているため、「最良の」ポータブルな方法はありません。血なまぐさい正当な理由なしにOS標準を破らないでください。

EDIT2:/etcまたはHKEY_LOCAL_MACHINEでシステム全体の設定を行っている場合は、設定が本当にグローバルであるかどうかを自問してください。その後、5分間待ってからもう一度質問します。それでも答えが「はい」の場合は、必ずグローバル設定を行ってください。通常のユーザーが書き込みアクセス権を持っていない、覚えている/etcHKEY_LOCAL_MACHINE、あなたのアプリをインストールすることはできません管理者権限のないその人を確保している、これを行うことによって。


最初の段落では、Path.Combineまたは類似のものを使用して、相対ルートの場所を一度%APPDATA%または〜に設定し、残りをコードに任せることができます.EDIT2には実際にクロスプラットフォームソリューションは存在しませんの。たぶん、その目的のためのクロスプラットフォーム構成ライブラリを書かれている人がいる、それは少なくとも、素晴らしいアイデアだろう...
タマラWijsman

1
@TomWij:有能な開発者であれば、どこでもリテラルを使用する必要がないことを理解できるはずです;)。それが変数の目的です。
チンメイカンチ

1
~/.config/applicaton* nixで優先される場所になりつつあります。
greyfade

@greyfade:私は実際にこれを実現したことはありませんが、あなたは正しいです。私のマシンでは、構成データを保管するアプリケーションの約4分の1が~そうしてい~/.config/appnameます。
チンメイカンチ

多くのアプリはWindowsで〜/ .appnameを使用します(これはドキュメントではなく、ユーザープロファイルディレクトリに相当します)。これは非常に迷惑です。これらのフォルダーは隠れません!
アラン・ピアース

3

私がしようとすると、レジストリを避け、それがされたの上に使用します。みんながそうすることを望みます。

私は、xml構成ファイルまたはbinファイル、あるいはローカルデータベース(SQLite)を保持することが好きです。


レジストリに入らないための+1。今は見つけることができませんが、MSの誰かがレジストリが間違っていることを認めていたことを読んだことを覚えているようです。
チンメイカンチ

1
XML部分を除き、あなたに同意します。単純な設定要件にはini(または単純なテキストファイル)を使用し、複雑なアプリにはSQLiteを使用します。
コーディズム

彼らは今それを認めていますか?1995年のことです。Mac OS Classicはそれを正しく実現しました。設定情報を保存するための集中管理された場所を提供する環境設定フォルダー。各アプリは独自のファイルに保存されます。 レジストリを初めて見たとき、「マイクロソフトは、すべての卵を1つのバスケットに入れていないということを聞いたことはありませんか?!?」
メイソンウィーラー

1
OSの設定(ファイル拡張子の登録など)を置く場所としては、大丈夫だと思います。しかし、Microsoftがそれを読み取り専用APIとして公開した場合、おそらく彼らはそれをめぐって訴えられ、とにかく書き込み可能にしなければならなかっただろう。
µBio

@ Chinmay、@ Mason、レジストリISNは間違いではありません。なぜなら、レジストリは単に構成データを保存するだけではありません(グループポリシー、ドメイン、レプリケーションを参照)。間違いは、マイクロソフトが開発者にどのように提案したか、そしてそれを使用するための良い基準がないことです。最終的にはアプリデータのゴミ捨て場になりましたが、これは本来の目的ではありませんでした。
マットオレニック

3

私の答えは、Chinmay Kanchiの答えとBioBuckyBallの答えの組み合わせです。

単純な構成のXML / Json、構成がユーザー依存の場合、デフォルトのOSアプリケーションフォルダーまたはデフォルトのOSユーザーフォルダーにパークされた複雑で大きな構成のSQLite。両方を使用できます。



1

ユーザー設定は通常

/home/<user>/.<application> 

たとえば、irssi設定の場合は/home//.irssi/configです


しかし、これはUnixの慣習です。Windowsはどうですか?Linuxでは、ユーザーのホームディレクトリをサブディレクトリであふれさせませんか?どうして/home/<user>/etc/application
Wizard79

@Lorenzo:ユーザーのホームディレクトリのフラッディングが問題になることはほとんどありません。
チンメイカンチ

1
構成設定は~/.config/application、物事を統合し続けるためにますます移動されています。私はこの動きに同意する傾向があります。
greyfade

1
@Lorenzo:これは、設定ファイルをに保存するWindowsの規則とまったく同じですAppData
greyfade

1
@クリス:まさか!:-)
Wizard79

1

推奨されるプラットフォーム固有のメカニズムを使用するのが最善だと思います。たとえば、OS Xでは、〜/ライブラリ/ Preferencesにプロパティリストを配置することをお勧めします。CocoaAPIには、そこから設定を保存および取得するための非常にシンプルなインターフェイスがあります。

アプリがクロスプラットフォームの場合、これをクラスまたはその他で抽象化できます。


0

レジストリに書き込むのはアプリの場所だけなので、インストーラーとアップデーターが簡単に見つけることができます。その他はすべて/ AppData / Company / Appのファイルに保存されます


-2

Javaアプリの場合、gsonは良い選択だと思います。設定オブジェクトを作成し、gsonを使用してそれらをJSONに、またはその逆に変換します。シリアル化されたblobの代わりに人間が読めるという利点があります。

編集:わかりましたので、多分それほど一般的ではありません...


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.