ヘルプ.Net設定オプションを理解する

Question

.NET v2のdll、ASP.net Webサイトなどの.Net設定のさまざまな設定オプションは本当に混乱しています。特に、UI /終了時に設定ファイルの影響を考慮する場合チェーンのユーザ側。

ので、例えば、私たちが使用してアクセス使用の設定で動作するアプリケーションのいくつか：メンバーがstongly型付けされているので

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

は今、このオプションはクールなようだ、と私はできませんVisual Studio 2005 IDEに存在しないプロパティ名を入力します。私たちが生きてボックスにデバッグDLLを解放し、誰かが内蔵されている可能性が、第二の設定がない場合（

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

：私たちは、コマンドライン実行可能なプロジェクトのApp.configファイルで、このような行で終わりますそれに埋め込まれたデバッグ接続文字列を使用して - EEK）

我々はまた、このようにアクセス設定をしている：我々はDLLコード、またはexeファイルからの設定にアクセスすることができますので、

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

は今、これらは/クールに見えますaspxコード、およびWebまたはApp.configで必要なのは次のとおりです。

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

ただし、設定ファイルに値が設定されていないか、文字列名が間違っている可能性があります。そのため、さまざまな問題があります。

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

私は何かが欠けているように感じる。現時点では、設定ファイル、暗号化などに値を書き戻すことができるアプリケーションには関心がありません。また、接続していない文字列を格納する最良の方法はDBにあると判断しました。次に、DB接続の問題が発生した場合にテキストの人に電話番号を格納するということですDBの外に保存する必要があります！

Answer 1

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

他の.NETの方法（私は.NETの前日にDBテーブルのアプリケーション設定を保存しているので区別しています）は、アプリケーション設定をapp.configファイルに格納し、生成されたSettingsクラス

私は逃げます。あなたの状況は異なって聞こえる。異なるアプリケーションがすべて同じサーバー上にある場合は、web.configの設定を上位にすることができます。しかし、そうでない場合、3つのアプリケーションすべてが共有設定を取得するための別個の「構成サービス」を持つこともできます。少なくともこのソリューションでは、3つの場所でコードを複製するのではなく、設定を追加するときにメンテナンスの問題が発生する可能性があります。しかし、少し上に設計された音。

私の個人的な好みは厳密な型付きの設定を使用することです。私は実際に自分の設定テーブルをデータベースに基づいて自分の強く型付けされた設定クラスを生成します。そうすれば、私は両方の世界のベストを尽くすことができます。 Intellisenseは私の設定とdbに格納された設定に注意してください（注：これはアプリケーションサーバーがない場合です）。

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

Answer 2

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

Answer 3

VS 2005+の[設定]タブを使用すると、強く入力された設定を追加して、最初の例のようにインテリセンスを得ることができます。

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber; 

これはApp.Configに物理的に格納されます。

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

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

Answer 4

私はRob Graysの答えをサポートしていますが、少し追加したかったのです。これはあまりにも明白かもしれませんが、複数のクライアントを使用している場合は、app.configにはインストール固有の設定がすべて格納され、データベースにはその他すべての設定が格納されます。

単一のクライアント（またはサーバー）アプリは多少異なります。ここは本当に個人的な選択です。データベース内のレコードのIDが設定されている場合は、をというデータベースに保存し、参照が削除されないようにすることができます。

Answer 5

はい - 私は頭痛の種になっていると思うRob descibes - 同じDBにアクセスする必要のある3つの独立したサーバーに5つまたは6つの異なるWebサイトとアプリケーションがあります。状況が進むにつれて、それぞれのWebまたはApp.configには、メインのDBアクセスDLLライブラリの設定を設定または上書きする設定が記載されています。

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