3

asp.net プロジェクトでカスタム構成セクションを実装するには、非常に多くの複雑さ、余分な作業、および余分なファイルが追加されるようです。そうは言っても、xml ファイル (または他のソース) から構成情報を読み取るだけの価値があるのはなぜですか? より高性能ですか？それはベストプラクティスですか？

4

2 に答える 2

3

（カスタム構成からの）値を保持する「オブジェクト」と、ばらばらのスカラーの束を作成できるためです。

また、構成値を別のファイルでヘルプにすることもできます (私が本当に気に入っているトリックです)。

別名、すべての SmtpSettings を ~separate SmtpSettings.config ファイルに入れました。また、「app.config」または「web.config」を無駄のない状態に保ち、誤って値を上書きすることはありません。

PS

そして、「DotNet」の方法でそれを行うと、将来の開発者はカスタム xml ルーチンを学習する必要がなくなります。別名、プロジェクトへのより一貫性のあるプロジェクトと「何をしてもうまくいく」という比較であり、コードを継承する人は誰でも、呪いの代わりに感謝します。あなた。

  <connectionStrings configSource="ExternalConnectionStrings.config" />

次に、ExternalConnectionStrings.config ファイルの内容

<connectionStrings>
  <add (blah blah blah) />

</connectionStrings>

覚えて。このファイル (または他の「トリック」) をコピーするには、POST-BUILD イベントを使用する必要があります。 app.config のように自動コピーされません。

「カスタム」ハンドラーでも機能するはずです。

  <configSections>

    <section name="FactoryMappingSettingsSection" type="MyConfigClassHandler, MyCompany.Framework.CrossDomain.Configuration"/>


  </configSections>

じゃあ後で：

  <FactoryMappingSettingsSection configSource="FactoryMappingSettings.config"/>
于 2013-07-15T20:21:46.467 に答える
0

いい質問だと思います。

唯一の利点は、それが .NET 開発者に知られていることだと思います。そのため、独自のソリューションで実装する新しいトリックを学ぶ必要はありません。

サーバーは web.config ファイルを保護しますが、XML ファイルを送信することを気にしないため、セキュリティも多少向上します。

于 2013-07-15T20:21:35.403 に答える