4

私は、コードで作業すること、IntelliSense を活用すること、および C# 言語のすべての機能をWCFで使用できるようにすることを強く好みますが、最終的に WCF 機能セットを制限する方向に進んでいないことを確認したいと考えています。アクセスできます。私の経験は WCF で非常に限られているため、構成ファイルを使用する利点がわかりません。特に、すべてをコードで実行できる場合 (?)。

注: .NET 3.5 を使用しています。

プログラムで WCF を使用して「すべて」を行うことができますか、または完全な WCF 機能セットには構成ファイルが必要ですか?

4

2 に答える 2

6

コードと構成で約 99.8% のことを実行できます。

認証にこれら 2 つを必要とする呼び出しでユーザー名とパスワードを設定するなど、コードでのみ実行できることもあります。

そして、構成でのみ実行できることがいくつかあるようです-一例については、この他の最近の SO の質問を参照してください。

しかし、コードを好むのであれば、ほとんどの場合は問題ないと思います。

マルク

于 2009-11-12T18:15:40.297 に答える
4

伸びすぎたコメント…

Marc_s の回答と質問の観点は良好です (私からの 2 つの +1)。

以下は、どちらにとってもニュースではないことは間違いありませんが、誰かがこれに遭遇し、純粋にプログラムによるアプローチの短所を認識していない場合に備えて、指摘したいと思います.

構成ファイルベースのセットアップ手段からプログラムによる構成への移行

  • 現場で物事を調整 (ハック!) する能力を失います -- 頼りになる唯一の手段は、バイナリを再コンパイルして再デプロイすることです。多くのシナリオ (私のシナリオを含む) では、これは n ではありません。
  • 構成ファイルでそれらをジャグリングすることにより、複数の構成セットを切り替えることができなくなります。

引用された「損失」はどちらも議論の余地があることを認めます。それらは悪い習慣を助長し、顧客にとって最も確実なソリューションを可能な限り迅速に実現することを妨げる可能性があります。

更新:使用するメカニズムを実装しましたChannelFactory<T>が、app.config からカスタマイズされた構成が存在する場合はそれを取得し、存在しない場合はデフォルトを提供します (私のシナリオは、私が他の誰かのプロセスのゲストであり、したがって、構成ファイルを簡単に更新できる、または更新済みであると想定することはできませんが、展開後に設定を微調整するオプションを失いたくありません)

于 2010-04-27T14:32:28.097 に答える