ASP.NETアプリケーションのカスタムコンフィグレーション（アプリケーション設定やその他のフレームワークの使用）

Question

.NETアプリケーション用のカスタムコンフィグレーションハンドラの作成方法を知っています。 StackOverflowには何が必要なのかをカバーする記事がたくさんあります。私は、ほとんどの時間をConfigurationElementから派生したクラスをノックアウトするのに費やしました。

私は、このアプローチには多くの作業が必要であると心配しています。予想以上に多くの作業があります。私はたくさんのクラスを作成し、それらをたくさんの属性で飾っています。この作業の多くがフレームワーク内に埋め込まれると考えることはできません。

Windowsフォームには、最近Application Settingsという機能が追加されました。これは設定のエディタを提供し、設定ファイルのタイプとタイプをシリアル化することで詳細を示すコードを作成します。アプリケーション設定は、カスタム設定を扱う際に苦労するように見えますが、これは特に設定セクションの形式が気に入らず、設定を保存し直さないようにしています。

だから、私のquesionsは以下のとおりです。

1. それがASP.NETサイト内アプリケーション設定メカニズムを使用するのが適切ですか？このようなアプリ内で、このメカニズムでperf/threadingの問題を発見できますか？
2. web.configからカスタム設定を読み込むのに苦労する他の（より良い）フレームワークはありますか？

Answer 1

Configuration Section Designerを参照してください。

Answer 2

私は特にアプリケーション設定機能が嫌いです。私は実際には何かが私のためにコードを自動生成するのを好んでいません。有用な例がありますが、自分のプロジェクトをコントロールできないという気持ちは嫌いです。

System.Configurationよりも「優れた」システムについては、私は考えることができません。ええ、おそらく多くのクラスと多くの属性で終わるでしょうが、あなたはのユーザーがユーザにとって使いやすい、高度にカスタマイズ可能な型安全な設定メカニズムを得るでしょう。最終的には、ユーザーエクスペリエンスは重要です。

Answer 3

適切ですか？確かに。たくさんの仕事？ Definetly。

あなたの製品を他の人が使用するために出荷する場合は、より適切だと思います。しかし、それが内部であれば、それは価値があるよりも仕事/頭痛になるかもしれません。

これは異例の意見かもしれませんが、私は2つ以外の設定ファイルでアプリケーション固有のものは好きではありません。

1. コンフィグプロバイダ
2. 接続文字列

私は、データベース内のすべての私の構成設定を入れて、設定は、データベースの設定の設定を上書きしますweb.configファイルで定義されています。

これは私のためにはうまくいきましたが、私は一般にカスタム設定セクションをできるだけ避けていました。