18
  • App.config を使用できます。ただし、キーと値のペアのみをサポートしています。
  • .Net 構成、構成セクションを使用できます。しかし、それは本当に複雑になる可能性があります。
  • 自分で Xml シリアライゼーション/デシリアライゼーションを使用できます。あなたのクラス - あなたのやり方。
  • 他の方法を使用できます。彼らは何になることができますか？...

これらの方法または他の方法 (ある場合) のうち、どちらを好みますか? なんで？

4

13 に答える 13

21

キーと値のペアが十分でない場合は、使用が複雑ではないため、構成セクションを使用します (複雑なセクションが必要でない限り)。

カスタム セクションを定義します。

        public class CustomSection : ConfigurationSection
        {
            [ConfigurationProperty("LastName", IsRequired = true,
            DefaultValue = "TEST")]
            public String LastName
            {
                get { return (String)base["LastName"]; }
                set { base["LastName"] = value; }
            }

            [ConfigurationProperty("FirstName", IsRequired = true, DefaultValue =
            "TEST")]
            public String FirstName
            {
                get { return (String)base["FirstName"]; }
                set { base["FirstName"] = value; }
            }

            public CustomSection()
            {

            }
        }

プログラムでセクションを作成します (まだ存在しない場合)。

           // Create a custom section.
            static void CreateSection()
            {
                try
                {

                    CustomSection customSection;

                    // Get the current configuration file.
                    System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(@"ConfigurationTest.exe");

                    // Create the section entry  
                    // in the <configSections> and the 
                    // related target section in <configuration>.
                    if (config.Sections["CustomSection"] == null)
                    {
                        customSection = new CustomSection();
                        config.Sections.Add("CustomSection", customSection);
                        customSection.SectionInformation.ForceSave = true;
                        config.Save(ConfigurationSaveMode.Full);
                    }
                }
                catch (ConfigurationErrorsException err)
                {
                    //manage exception - give feedback or whatever
                }

            }

次の CustomSection 定義と実際の CustomSection が作成されます。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="CustomSection" type="ConfigurationTest.CustomSection, ConfigurationTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" allowLocation="true" allowDefinition="Everywhere" allowExeDefinition="MachineToApplication" overrideModeDefault="Allow" restartOnExternalChanges="true" requirePermission="true" />
  </configSections>
  <CustomSection LastName="TEST" FirstName="TEST" />
</configuration>

セクションのプロパティを取得します。

    CustomSection section = (CustomSection)ConfigurationManager.GetSection("CustomSection");
    string lastName = section.LastName;
    string firstName = section.FirstName;
于 2008-09-22T20:56:53.403 に答える
12

それを回避できる場合は、App.Config を使用しますが、より複雑なものが必要な場合は、カスタム構成セクションを使用します。はい、最初に理解するのは面倒ですが、私の意見では、統一された構成ソースとすべての設定の使い慣れた構成は、時間をかける価値があります。

于 2008-09-22T20:29:22.173 に答える
4

構成をデータベースに入れます。アプリを複数のマシン (クライアント サーバー アプリなど) で実行する場合、すべてのマシンごとの構成システムは PITA です。単一の構成領域は、構成を配置する最良の方法です。それを管理するためのGUIを書いてください。とても幸せです。

app.config ファイルを 200 個のクライアント ボックスに展開する..特に 1 つが見落とされた場合は、楽しくありません (実際、そうです、私を信じてください)。

于 2008-09-22T21:06:37.233 に答える
2

以前はネットワーク/システム管理者でしたが、現在はデータベース アプリケーション用の内部ユーティリティを開発しています。私が見つけたのはこれです：

シンプルなネストされていない構成ファイルは、リソースにアクセスする場所をあまり変更しないアプリケーションに最適です。

より複雑なものは、管理 UI を使用してデータベースに入れる必要があります。これは、通常のビジネス ユーザーにのみ適用されます。データベースの破損が心配な場合は、複雑な構成ファイルのアプローチを使用してください。ファイルは、データベースよりも壊れにくい傾向があります。

ここで、ユーザーが他の開発者である場合、構成を保存するために何を使用するかについて、より多くの柔軟性が得られます。

于 2008-09-22T20:38:30.717 に答える
1

キー/値の構成は、単純な構成ファイルに対してはかなりうまく機能します。ファイルが大きくなり始め、保守が困難になると問題になります。構成ファイルを「共通」および「特定の」アプリケーション構成に分割し始めました。ファイルアクセスはアプリに対して透過的です。「共通」の値はほとんどの場合同じですが、「特定の」値はデプロイされたアプリケーションごとに異なります。

于 2008-09-23T10:53:36.980 に答える
1

カスタム xml 構成ファイルを使用します。ここでは、環境 (dev/qa/prod) ごとに異なる構成ファイルが使用されます。構成ファイルは、サービスのホスト/ポート構成などで動的にインスタンス化されるテンプレートです。これにより、テンプレートのインスタンス化コードで処理できるため、マルチ環境とフェイルオーバーが非常に簡単になります。

もちろん、構成がほとんどなく、複数の環境に関心がない場合は、 app.config がより標準的であり、おそらく最良の方法です。

于 2008-09-22T20:33:19.030 に答える
1

カスタム xml 構成ファイルを使用します。各設定には、キー、値、およびタイプがあります。

これには、すべての設定を含む 1 つのメイン セクションと、特定の環境 (開発、ステージング、ライブ) の設定オーバーライドを含む追加セクションがあります。これにより、展開時にファイルのセクションを置き換える必要はありません。特定の設定またはそれらすべてを含む辞書を取得するために呼び出すことができる小さなラッパーがあります。

最近、構成ファイルを読み取り、厳密に型指定された静的設定クラスを作成するT4 テンプレートを作成しました。これにより、大幅な時間の節約になりました。

于 2008-12-02T23:51:08.197 に答える
1

私はNameValueCollectionHandlerが最も簡単で最適だと思います。通常、configSource 属性を介して外部構成ファイルにリンクします。

絶対最小構成を構成ファイルに入れようとしましたが、そのほとんどは、展開環境を自己認識しているアプリケーションを使用してコードで構成されています (マシン名や既知の場合は IP アドレスなど)。もちろん、これには環境に関するより多くの事前計画と知識が必要でしたが、展開時の頭痛の種ははるかに少なくなりました。

于 2008-09-22T20:34:54.470 に答える
0

呼び出し元のアセンブリに関連付けられた「.settings」ファイルから構成データを返す独自の特別なクラスをローリングすることができました。ファイルはXMLであり、設定クラスはそれをXDocumentとして公開します。さらに、この設定クラスのインデクサーは、/ settings/settingノードから要素値を返します。

設定へのキーと値のペアのアクセスが必要な単純なアプリケーションに最適です。また、独自の構造を定義し、System.Xml.Linqを使用してXMLドキュメントをクエリする必要がある複雑な設定に最適です。

独自にローリングすることのもう1つの利点は、FileSystemWatcherとコールバックアクションタイプを使用して、実行時にファイルが変更されたときにメソッドを自動的に起動できることです。

于 2008-09-23T10:41:36.243 に答える
0

ほとんどの場合、カスタム xml ファイルと Xml シリアル化メソッドを使用して、この構成ファイルを読み書きすることを好みます...キーと値のペアに制限されず、実装が複雑ではありません...

于 2008-09-23T08:36:18.230 に答える
0

dataset.WriteXML()/dataset.ReadXML() は、app.config がそれをカットしなくなったときに、私にとってはかなりうまく機能します。

于 2008-09-22T21:02:34.967 に答える
0

Spring.Net などの IoC コンテナに設定のほとんどを保持しています。

于 2008-09-22T20:30:16.260 に答える
0

.NET 3.0 を使用できる場合、XamlReader/XamlWriter は設定を保存するのに非常に便利です。次の場合、任意の .NET オブジェクトを XAML に読み書きできます。

  • オブジェクトにはパラメーターなしのコンストラクターがあります
  • 読み取り/書き込みするプロパティには、パブリックのゲッターとセッターがあります

設定オブジェクトを属性で装飾する必要がないことは特に素晴らしいことです。

于 2008-09-22T20:39:05.007 に答える