5

特にチェーンのUI /エンドユーザーエンドでの構成ファイルの影響を考慮すると、.Net v2のdll、ASP.net Webサイトなどの.Net構成のさまざまな構成オプションに本当に混乱しています。

したがって、たとえば、私が使用するアプリケーションの一部は、アクセスする設定を使用します。

string blah = AppLib.Properties.Settings.Default.TemplatePath;

このオプションはクールに思えます。なぜなら、メンバーの型指定が厳密であり、Visual Studio 2005 IDE に存在しないプロパティ名を入力できないからです。コマンドライン実行可能プロジェクトの App.Config では、次のような行になります。

<connectionStrings>
    <add name="AppConnectionString" connectionString="XXXX" />
    <add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>

(2 番目の設定がない場合、誰かがデバッグ dll をライブ ボックスにリリースして、デバッグ接続文字列が埋め込まれた状態でビルドされた可能性があります。)

次のように設定にアクセスすることもできます。

string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];

dll コードまたは exe / aspx コードから設定にアクセスできるため、これらはクールに見えます。Web または App.config で必要なのは次のとおりです。

<appSettings>
   <add key="TemplatePath_PDF" value="xxx"/>
</appSettings>

ただし、もちろん、値が設定ファイルに設定されていないか、文字列名が間違って入力されている可能性があるため、別の問題が発生しています。

だから...私の理解が正しければ、前者の方法は強力な型付けを提供しますが、dllと他のプロジェクトの間で値を共有することはできません。後者はより良い共有を提供しますが、タイピングは弱くなります。

何かが足りない気がします。現時点では、アプリケーションが値を構成ファイルに書き戻したり、暗号化したり、そのようなことをできるかどうかについても気にしていません。また、接続以外の文字列を格納する最善の方法はDBにあると判断しました...そして、DB接続の問題が発生した場合に備えて、電話番号をテキストの人々に格納する必要があります。 DBの外部に保存する必要があります!

4

5 に答える 5

3

VS 2005+ で [設定] タブを使用すると、最初の例のように、厳密に型指定された設定を追加して IntelliSense を取得できます。

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

これは App.Config に物理的に保存されます。

構成ファイルの appSettings 要素を引き続き使用することも、独自の ConfigurationElementCollection、ConfigurationElement、および ConfigurationSection サブクラスをロールすることもできます。

接続文字列以外の場合の設定、データベース、または構成ファイルの保存場所については、アプリケーションのアーキテクチャによって異なります。すべてのクライアントで共有されるアプリケーション サーバーがある場合は、アプリ サーバーの App.Config で前述の方法を使用します。それ以外の場合は、データベースを使用する必要がある場合があります。各クライアントの App.Config に配置すると、バージョニング/展開の問題が発生します。

于 2008-09-12T00:06:23.457 に答える
2

Nij、私たちの考え方の違いは、私たちの視点の違いから来ています。主に WinForms クライアントを使用するエンタープライズ アプリの開発を考えています。この例では、ビジネス ロジックはアプリケーション サーバーに含まれています。各クライアントはダイヤルする電話番号を知っている必要がありますが、各クライアントの App.config に配置すると、その電話番号が変更された場合に問題が発生します。その場合、アプリケーション構成情報 (またはアプリケーション全体の設定) をデータベースに保存し、各クライアントにそこから設定を読み取らせることは明らかです。

もう 1 つの .NET の方法 (.NET より前の時代にはアプリケーション設定を DB テーブルに保存していたため、区別しています) は、アプリケーション設定を app.config ファイルに保存し、生成された Settings クラスを介してアクセスすることです。 .

余談です。あなたの状況は違うように聞こえます。すべての異なるアプリが同じサーバー上にある場合は、設定をより高いレベルの web.config に配置できます。ただし、そうでない場合は、3 つのアプリケーションすべてが通信して共有設定を取得する別の「構成サービス」を使用することもできます。少なくともこのソリューションでは、コードを 3 か所で複製していないため、設定を追加するときにメンテナンスの問題が発生する可能性があります。ただし、少し設計されすぎているように聞こえます。

私の個人的な好みは、強い型付け設定を使用することです。データベース内の設定テーブルに基づいて、厳密に型指定された独自の設定クラスを実際に生成します。そうすれば、両方の長所を活かすことができます。自分の設定とデータベースに保存されている設定に対するインテリセンス (注: アプリ サーバーがない場合)。

私もこのための他の人々の戦略を学ぶことに興味があります:)

于 2008-09-12T02:37:10.723 に答える
0

Rob Grays の回答を支持しますが、少し追加したいと思います。これは非常に明白かもしれませんが、複数のクライアントを使用している場合、app.config はインストール固有のすべての設定を保存し、データベースはそれ以外のほとんどすべてを保存する必要があります。

単一のクライアント (またはサーバー) アプリは多少異なります。ここでは、より個人的な選択です。注目すべき例外は、設定がデータベース内のレコードの ID である場合です。この場合、参照が削除されないように、外部キーを使用して常に設定をデータベースに保存します。

于 2008-09-12T00:20:00.273 に答える
0

はい - 私 / 私たちは頭の痛い状況にあると思います。現状では、それぞれに独自の Web または App.config があり、設定で説明されている設定および/またはメインの DB アクセス dll ライブラリの設定をオーバーライドしています。

ロブ - あなたがアプリケーション サーバーと言うとき、私はあなたが何を意味するのか分かりませんか? 私が考えることができる最も近いことは、ディレクトリ階層の上位にある web.config に配置することで、少なくとも同じマシン上のサイト間でいくつかの設定を共有できるということです...しかし、これも私が調査できたものではありません...強いタイプまたは弱いタイプのルートのどちらが「より良い」かを理解することがより重要であると考えました。

于 2008-09-12T00:39:10.677 に答える
0

あなたの混乱は、最初の例が.NETの一部ではなく、自家製のライブラリであるように見えるという事実から来ていると思います. 構成マネージャーの例は、組み込み機能の例です。

于 2008-09-11T23:50:13.340 に答える