5

さまざまなクライアントに展開するためのASP.Netアプリケーションの構成を管理するのに問題があります。調整が必要なさまざまな設定の膨大な量には多大な時間がかかり、現在の構成方法は複雑すぎて、この責任をサポートパートナーに押し出すことができません。

これを処理するためのより良い方法、または調査するための優れた情報源についての提案はありますか？

現在のやり方：

  • AppSettings.xmlなど、Web.Configで参照されるさまざまなxml構成ファイル。
  • 特定のサイトの構成は、重複した構成ファイルに保持されます。
  • サイトに固有のデータのリストを含むテキストファイル
  • 場合によっては、データベースへの手動による1回限りの変更
  • Windsor IOCのC＃構成。

私たちが抱えている特定の問題：

  • さまざまな機能が有効になっているさまざまなサイト、話し合う必要のあるさまざまな外部サービス、さまざまなビジネスルール。
  • さまざまな展開タイプ（ライブ、テスト、トレーニング）
  • 構成キーはバージョン間で変更されます（追加、削除）。つまり、重複するすべてのファイルを更新する必要があります。
  • アプリケーションの実行中にキーを変更できる必要があります

これにどのように取り組むかについての現在の考えは次のとおりです。

  • 構成を動的にコンパイルされたコード（おそらくBoo、Binsor、またはJavaScript）に移動します
  • 何らかの形式の差分/マージ構成があります。デフォルト構成をライブ/テスト/トレーニング構成およびサイト固有の構成と組み合わせます
4

3 に答える 3

2

どちらの方法でも、構成に単一の「信頼できる情報源」の概念を持たせることは価値があると思います。

一部のコンポーネントに独自の特殊な形式で構成を提供する必要がある場合は、複製で問題ありません。

しかし、正気を保つために、アプリケーションに関連するすべての構成を設定する1つの場所を目指し、それをWeb.config内のエントリに変換するための明確に定義されたメカニズム、およびその他の構成メカニズムを目指す必要があると思います。サポートする必要があります。

サポートパートナーのスキルのレベル（XMLを破るかどうか）によっては、この「信頼できる情報源」構成ファイルのすべてのノブを「変換/更新コードを実行して適用し、Web.configとその仲間に必要な変更を加えます。

次に、さまざまなサイト/顧客の構成を管理するために、理論的には1つの構成ファイルを管理する必要があります。

注： ASP.NET 4.0では、ビルド時の構成変換メカニズムが利用可能になります（http://blog.hmobius.com/post/2010/02/17/ASPNET-40-Part-4-Config-Transformation-Filesを参照） .aspx）。これにより、このタスクが簡単になる場合があります。これは、Web以外のプロジェクトのいくつかのハックで使用できるようです（http://philbolduc.blogspot.com/2010/03/using-config-transforms-outside-web.htmlを参照）。

ただし、展開時にこれらの変更を行う必要がある場合は、これを行うためのカスタムツールの作成に行き詰まる可能性がありますが、追加できるようにしたい場合は、XDT変換が適しているように見えます。アイテムを更新/削除します。

于 2010-04-02T23:37:16.720 に答える
0

構成キーを操作するためのカスタム .net ユーティリティと組み合わせた自動化用の NAnt スクリプトを検討することを検討してください。

于 2010-03-23T21:24:06.537 に答える
0

上記の構成項目を使用するコードが、管理/変更可能なコードである場合 (およびすべてが管理されたコード空間/C# で実行されている場合)、設定を取得するメソッド呼び出しを、少なくとも GetString を持つシングルトンのようなクラスへの呼び出しに移植することを検討します。 （）メソッド。

GetObject() は非常に便利です (.Net XML シリアライゼーションの内容を確認してください - アメリカ人は「z」で綴ります: シリアライゼーション) ... 多くのものに役立ちますが、関連する構成アイテムのパッケージ化を開始できることも意味します。ストア内の単一のエントリ。

単一のストア (キャッシュされたアクセスを持つデータベース テーブル) を使用するか、構成アイテムが格納されている場所をカプセル化するためだけに新しい構成ファサードを使用することに関しては、それはあなた次第です。どこを見ればいいのか、どこを変更すればよいのか、常に正確に把握できます。すべての Web サービス参照 (WCF またはその他) は、ランタイムが提供する文字列を使用して構築および呼び出すことができます ... :)

キーの値をキャッシュするという点では、スタックのオーバーヘッドが管理しやすいため、メモリ内キャッシュ (小さなアプリの場合) を使用します... memcache のようなものがここで機能する可能性があります (構成ストアは、TCP 経由で/ネットワークのどこかにアクセスされます)。 ...

編集次のようなもの：

public class ConfigurationStore
{
    private static ConfigurationStore _instance = null;

    public static ConfigurationStore Instance {
        get {
        if(_instance == null)
        {
            _instance = new ConfigurationStore();
        }

        return _instance;
        }
    }

    public string GetValue(string key)
    {
        ....
    }

    public Object GetObject(string key)
    {
        ...
    }
}
于 2010-03-23T15:32:48.363 に答える