web.config（カスタムセクション/ appSettingsエレメント）のデータを格納することとそれをクラスに格納すること

Question

ファイルのappSettings要素（またはカスタムセクション内）にデータを格納するほうが、クラス？

カスタムセクションを使用すると、データを変更するときにコードを再コンパイルする必要はありませんが、弱い引数です。特にWebサイトを使用している場合は、コードが変更されたときに自動的に再コンパイルされます。

は、web.configファイルに設定を置くことによって、あなたに

Answer 1

をありがとう、あなたは中央の場所でそれらのすべてを持っています。

また、Webサイトを展開するときに、そのWebサイトを1回プリコンパイルすることもできます。後で（別の再コンパイルなしで）ソースを変更することはできません。

Answer 2

コードを再コンパイルするだけのことではなく、コードを再デプロイすることです。通常は、Webサーバーにコードをデプロイしないで、バイナリとaspx/htmlファイルをデプロイするだけです。コードで設定データをハードコードする場合は、ライブラリやアプリケーションを再構築して再デプロイする必要があります。これは、サーバーに変更を加えることです。これはweb.configの更新だけではありません。

Answer 3

その場で変更することができ、クラス構造に関係なく使用することができます。構成は、コードとは独立した単一のファイルを変更して維持することによって、開発者のマシンごとにステージングから展開環境に変わります。サイトの異なる領域で* .configマスキングを利用できます。

何でも設定可能なハードコードは失敗のレシピです。絶対にがあなたを噛んでしまいます - これはあなたがそれを信じていないとしばらく待つだけの経験です！

Answer 4

設定を管理して更新するのはずっと簡単です。

、あなたの開発を行うために、メモ帳を使用して、サーバー上でコードを入れている場合は、私はほとんど利点があることが同意するだろうが、しかし、あなたは、Visual Studioを使用している場合、あなたビルドあなたのウェブサイトやそれを公開すると、サーバー上のテキストソースコード（.csまたは.vbファイル）を更新するだけでなく、事前にコンパイルされたdllを公開しています。その時点で設定を更新するときは、テキストファイルを変更するだけでweb.configの内容を更新することができます。ここでは、他の変更と同様に、Webサイト全体を再コンパイルして公開する必要があります。

経験から、Webサイトの作業を行うために必要なすべてがソース管理になっていることを慎重に考えなかった他の開発者を引き継ぐと、それは難しくなります。私は今、過去に非標準のプラクティス（親切にそれを置く）のために、私たちがそれの巨大な塊を更新することができないウェブサイトで立ち往生しています。

サイトを再公開せずに何かを更新できることは、私の状況では大きな祝福です。貧しいメンテナンスプログラマーがあなたのコードを引き継ぐのは誰なのか分かりません。

彼または彼女に親切にしてください。簡単に変更することができます。

Answer 5

web.configファイルにデータを置くことで、環境依存データの異なるさまざまな環境で同じコードを実行することもできます。これは、テストデータベース接続文字列を使用してステージングを行い、本番データベース接続文字列を使用して運用環境で同じWebサイトコードを実行することを意味します。あるいは、開発者がコードを変更せずに独自のテスト用にデータを設定できるようにすることもできます。