2

PayPal の実装用に新しい C# プロジェクト (非 Web) を作成しました。次のような一連の構成文字列があり、それらを保存する最良の方法を見つける必要があります。私が作成したさまざまなラッパー クラスは、これらの文字列を使用しています。また、これはあらゆる Web プロジェクトやバックエンドで使用できるプロジェクトです。そのため、他のアプリケーションが必要としないように、これらすべての文字列キーを PayPal C# プロジェクトに集中させて維持するための優れた方法が必要です。私のラッパー プロジェクトを使用している他のアプリは、これらの文字列について何も知らないか、必要があります...私のプロジェクトがそれらを保存します。

それで、どこ？C# 非 Web プロジェクトで Web.Config を使用する必要がありますか? アプリ構成を使用しますか? それらをDBに保存しますか（いいえ、悪い考えです）。または、たとえば Constants.cs クラスに定数として保存しますか?

それらを定数クラスに格納することが安全かどうかもわかりませんか? ここでの私の最良のオプションは、web.configまたは何らかの構成を非Webプロジェクトに追加し、そこに保存することです。

4

6 に答える 6

1

少し前に PayPal の実装を行いました。私たちが最終的に行ったことは、これらの機密文字列を暗号化された文字列として web.config に保存することでした。あなたのシナリオでは、同様のこと（web.configに暗号化された文字列として保存する）を検討するかもしれませんが、イントラネットのみのWebサービスでラップし、1つのドメインアカウントにのみアクセスを許可することで集中化します。これにより、1 つのドメイン アカウント以外は Web サービスを呼び出して資格情報やその他の PayPal 固有のオブジェクトを取得できなくなります。

于 2010-01-29T18:47:59.120 に答える
1

これを行う「標準的な」.NET の方法は、app.config を作成してそこに配置することです。これらは、作成中のライブラリ プロジェクトを呼び出すプロジェクトの web.config または app.config にコピーする必要があります。

于 2010-01-29T18:43:49.023 に答える
1

.NET 構成システム (System.Configuration) を使用するだけで、構成設定がどこに保存されているかを気にする必要はありません。

コードが Web 以外のアプリケーションから使用されている場合、これらの設定はアプリケーションの .config ファイルで構成できます。Web アプリケーションは web.config を使用します。

名前は似ていませんが、app.config と web.config は同じ API を使用します。

于 2010-01-29T18:43:55.217 に答える
1

文字列がコンパイル時に決定され、変更されない場合は、リソース ファイルを使用します。

永続的なストレージが必要な場合は、システム レジストリを使用することもできます。私自身もこれに手を出しており、重大なタイプミスを減らすためにリソース ファイルも使用しています。

// Get key
RegistryKey appKey = Registry.CurrentUser.CreateSubKey(Resources.keyAppPath);

// Read from key
string _configStr = (string)appKey.GetValue(Resources.keyConfigStr, string.Empty);

// Write to key
appKey.SetValue(Resources.keyConfigStr, _configStr);

Resources.keyAppPathのようなものです"Software\[Company]\[App]"

Resources.keyConfigStrキーの名前です。

他の人が述べたように、セキュリティが特定のデータの問題である場合は、暗号化のレイヤーを追加してください!

于 2010-01-29T18:58:51.813 に答える
0

構成は、全体的なアーキテクチャによって異なります。消費するアプリケーションが設定について何も知らないと予想される場合は、これらの設定を取得して明示的なプロパティとして出力するクラスを作成するのが最善の方法です。アプリケーションを再コンパイルして再デプロイすることなく変更できるため、web.config の何らかのバージョンにそれらを配置することが常に最善の方法です。また、ソース管理やさまざまなレベルの構成 (開発、テスト、運用、運用前など) の管理についても考慮する必要があります。

アクセスしているサーバーのレベルまたはタイプに基づいて、独自の構成セクションと接続文字列セクションを作成する web.config メソッドを採用しました。次に、組み込みの ConfigurationManager とほぼ同じ方法でそれらにアクセスする独自の「ConfigurationManager」クラスを作成しました (そのため、その使用法は他の開発者には透過的です)。次に、web.config に任意の設定を含めることができ、ASP.Net 構成標準と一致する方法で、クラス自体を企業全体で同じように使用できます。設定が必要な人は誰でも myConfigurationManager.AppSettings(key) を呼び出し、問題のサーバーのレベルに基づいて適切な設定を受け取ります。構成ファイルのソース管理はサーバー間で異なる必要はありません。

同様に、app.config をこのように構成して、拡張構成サポートを提供できます。

于 2010-01-29T18:45:57.690 に答える
0

それらを保持する単純なクラスを作成し、他のアプリによって同じクラスに読み戻される場所にクラスを xmlSerialize することができます。

于 2010-01-29T18:48:39.013 に答える