3

さて、これは私を少し混乱させました。私は次のものを持っています：

string csvOfAttributes = CableSolve.Web.Properties.Settings.Default.GenerateBoothReportAttributes;

そして私のweb.configで：

<CableSolve.Web.Properties.Settings>
  <setting name="GenerateBoothReportAttributes" serializeAs="String">
    <value>327, 329, 330, 369, 342</value>
  </setting>
</CableSolve.Web.Properties.Settings>

これについて2つの質問があります。

  • web.configファイルから設定を省略すると、コンパイルエラーが発生します。これはどのように可能ですか？Web.configはユーザーが編集できます。実行時エラーのみが予想されます。アプリケーションをコンパイルしてデプロイすると、ユーザーがこの設定の名前を編集します。コンパイルされたコードは壊れませんか？
  • この設定をweb.configファイルのappConfigセクションに保存できる可能性があります。値にアクセスするには、ConfigurationManagerを使用します。設定がない場合にのみ、実行時にnullオブジェクトを受け取ります。コンパイル中に発生するエラーを好む傾向があるため、これはあまり有利ではないように見えますが、これら2つのオプションの違いは何であり、いつ使用する必要があるのか​​疑問に思います。
4

1 に答える 1

0

答えは主に質問に含まれていると思います。全体の違いは、基本的なキーと値のペアのスキーマとより複雑なスキーマの違いです。ひいては、違いは弱い型と強い型、および実行時とコンパイル時の違いに関連しています。一般に、.NETがJavascriptよりも「優れている」のと同じ意味で、後者の方が優れています。予測できない、追跡が難しい方法でエラーがアプリケーションに発生するのではなく、エラーが早期に通知されます。強力なスキーマ設定の例外には、次のものがあります。

  • アプリケーション要件は進化しているため、スキーマを固定したくない
  • さまざまな開発者またはアプリケーションが使用するルートレベルの構成で作業しています
  • 「無効な」構成を許可し、実行時にそれらを処理する
于 2012-04-10T20:34:10.187 に答える