2009-03-27 12 views
17

どのようにWindowsレジストリが使用されるのですか?少量のユーザー設定を保存するのは問題ないと思いますが、そこにすべてのユーザーデータを保存するのは悪い習慣と考えられますか?私はそれがデータセットに依存すると思います。つまり、100KBほどの異なるキー/値ペアで、2KB未満の少量のデータについてはどうでしょうか。これは悪い習慣ですか?フラットファイルやSQLite DBはより良い方法ですか?Windowsレジストリのベストプラクティス

答えて

10

単純なユーザー設定項目とユーザーデータは、単純なXML構成ファイル、SQLLite db、またはMS SQL Server Compact dbのいずれかに格納する方がよいです。正確な記憶媒体は、実装の詳細に依存する。

私は頻繁に設定する必要があり、ユーザーが変更/表示する必要がないことにのみレジストリを使用します。たとえば、誤ってユーザーがデータを削除しないようにするには、暗号化されたライセンス情報をレジストリに保存しておく必要があります。

+2

どのような種類の「セキュリティとその他の意味」を参照していますか? – quux

+0

ファイルシステムのセキュリティへの影響がレジストリのものとどのように違うのか分かりません。 – Alex

+0

Windows 7のレジストリにアクセスするには高度が必要です。実際には、自動スタートなどのためにレジストリに接続しようとしている場合を除き、実際には必要ありません。可能な限り特権。 –

2

マイクロソフトでは、Windowsレジストリの代わりに独立したストレージを使用することを推奨していると思います。

Here's .Netでの使用方法を説明した記事。

これらのファイルは、Windows XPのDocuments &設定\\ローカル設定\アプリケーションデータ\隔離保存の下にあります。データは.datファイルにあります

+0

Isolated Storageのファイルには特定のアセンブリでしかアクセスできないため、アンインストーラでISからユーザー設定を削除するなどの操作は簡単にできません。開発中にトラブルシューティングのためのデータファイルを手動で見つけるのも面倒です。必要な場合、複数の.exesがすべてデータファイルを共有できるように、企業が使用する固有のキー(CompanyName \ ProductNameまたはGUIDなど)を生成する方法が必要です。 ISは死んでいる。ロングライブ%AppData%。 –

5

それぞれのユーザーは、既にアプリケーションユーザーデータの格納専用のWindowsにディレクトリスペースがありますので、そこにユーザーレベルのデータ(環境設定など)を格納するために使用します。

のC#で

、私はこのような何かをすることによってそれを得るだろう:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); 

一般的に、私はそこにSQLiteのファイルを保存するか、どんなアプリケーションに適しています。

6

データを格納するためにレジストリを使用することには、主に1つの問題があります。それはあまりユーザーフレンドリーではありません。ユーザーは、設定をバックアップしたり、別のコンピュータにコピーしたり、破損した場合にはトラブルシューティング(またはリセット)することはほとんどありません。ソフトウェアの動作を参照してください。

私の経験則は、OSとの通信にのみレジストリを使用することです。スタートアップ時に実行するファイルタイプの関連付け、アンインストーラエントリ、プロセス、これらのことは明らかにレジストリになければなりません。

ただし、アプリケーションで使用するデータは、App Dataフォルダのファイルにのみ属しています。 (Microsoftが現在あなたに使いたい3つ以上のApp Dataフォルダのいずれかを使用)

+1

パワーユーザー以外のユーザーはそうではありませんが、%APPDATA%/ MyAppにファイルをバックアップすることも困難です。レジストリはエクスポートとインポートが簡単です - あなたのツリーを(HKCU/Software/MyAppまたはwhereeverで)右クリックしてエクスポートします。ディレクトリを圧縮するだけで簡単です。 – gbjbaanb

1

私には、あなたがそこに置くべきではないことを考えるのが容易に思えます。 :エディタの「最後に開いたファイル」やプロジェクトごとのオプションなどの動的データ。あなたのアプリがレジストリ(ファイルの削除、システムクラッシュなど)との同期を失い、もはや有効ではない情報を取得して、おそらくユーザーをデッドロックしてしまうと、本当に面倒です。

以前の仕事では、そこにデータ転送の完了率を保存した人がいました。新しい値が10k程度ごとに書き込まれ、GUIがこの値を毎秒取得してタイトルバーに表示できるようにしました。

+0

Yikes!過去に私が使っていたもののいくつかが悪いと思った! (いいえ、本当に分かち合うつもりはありません) –

+0

ああ、来て!恥ずかしがらないでください!正直言って誰にも言わないよ! – Treb

+0

私はそれを取得しません。なぜこの男は自分のアプリの一部でレジストリに書き込んだら、表示のためにレジストリから値をポーリングして読み込みますか?これは、永続性の特定のメカニズムとは何の関係もない方法で、愚かなようです。 – MusiGenesis

2

私は差別化になります。

実行するためのアプリのために必要とされるアプリケーション固有の構成データは、例えば、そこにある一方で接続するIPアドレス、どのようなファイルの種類などに使用するフォルダ、ユーザーごとの設定は重要ではありません。 設定ファイルに入れたもの、単純なもののためのini形式、もっと複雑なものがあればxml。

一方、ユーザの設定ごとにはほとんどありません(最良の例:ウィンドウの位置とレイアウト)。設定ファイルが混乱するのを避けるために(一部のユーザーは自分自身を編集したいので、あまりにも明確に配置されたエントリは必須です)、私はそれらをレジストリに入れたいと思います(レジストリに設定がない場合は控えめなデフォルトが設定されています)見つけることができます)。

私は主にそれを好きですistmatt sais:%APPDATA%フォルダ内に設定ファイルを保存します。通常%APPDATA%\ApplicationNameには、.NETのデフォルトのAPPDATA%\CompanyName\ApplicationName\Versionが嫌いです。このレベルの詳細と複雑さは、ほとんどの中小規模のアプリケーションにとって逆効果です。

私はMarcelo MDの例では、最近使用したファイルをレジストリに保存していないという意見に同意します。 IMOこれはまさに揮発性の種類のユーザー固有の情報で、そこに格納することができます。 (ないは何をすべきかの彼の例はいえ、非常に良いです!)

4

あなたのアプリは、管理者がグループポリシーツールを使用してレジストリを微調整することができますことを心に留めておく、「企業内」に展開されようとしている場合。たとえば、firefoxがプロキシサーバーのようなものにレジストリを使用した場合、管理者はActive Directory内の標準ツールを使用して設定を行うことができるため、展開が簡単になります。あなたが他のものを使っているなら、私はそんなことは非常に簡単にできるとは思わない。

レジストリを一括して却下しないでください。管理者がネットワーク上で構成の一部を標準化する可能性がある場合は、設定をレジストリに入れてください。

+0

また、エンタープライズフレンドリーでありたい場合は、レジストリの[ポリシー]セクションから意図的に設定を読み込み、ADMおよび/またはADMXテンプレートを提供してアプリケーションと一緒に使用することもできます。 –

15

私は逆説的な考え方をとるつもりです。

レジストリは、すべてのタイプの構成データを格納するのに最適な場所です。一般に、ほとんどの設定ファイルよりも高速で信頼性が高くなります(レジストリの個々の操作は処理されるため、書き込み中にアプリケーションがクラッシュした場合、レジストリは壊れません - 一般的にはiniファイルではそうではありません)。

Marcelo MDは完全に正しいです:操作のパーセンテージがレジストリ(または他の非揮発性ストレージ)に格納されているようなものを保存するのはひどい考えです。一方、最も最近使用されたファイルのようなデータを格納することは問題ありません。レジストリはこの種の問題のために構築されました。

MRUリストについて話しているこの記事の他のコメント作成者の多くは、MRUリストがアプリケーションクラッシュのために同期しなくなった場合に起こる問題について説明しました。 MRUリストをフラットファイルにユーザごとのストレージに格納する方が良い理由は何ですか?

また、レジストリにデータを格納する "セキュリティの影響"についてもわかりません。レジストリはファイルシステムと同じくらい安全です。レジストリとファイルシステムは同じACLメカニズムを使用してデータを保護します。

ユーザーデータをファイルに保存する場合は、少なくとも%APPDATA%\ CompanyName \ ApplicationNameにデータを格納する必要があります。つまり、2人の異なる開発者が同じ名前のアプリケーションを作成する場合「Media Manager」アプリケーションがそこにありますか?)衝突はありません。

関連する問題