この例のために、株式相場表示のようなアプリケーションを想像してみてください。ダニを収集し、データベースに保存するために送信するというWCFの明らかなアプリケーションがありますが、内部的にはどうでしょうか。
WCFを使用して、同じアプリケーションのモジュール間の通信を定義および調整しますか？私たちの株式相場にはウィジェットがあり、1つは最後の価格を示し、1つは価格の変化に応じて更新されたチャートを示し、もう1つは最後の2つの価格の差を示します。
それらすべてを同じプロセス内でWCFを介して調整できますか？そして、あなたは？
それらはすべてWCF通信によって調整できますが、それが良い考えかどうかはわかりません。あなたが与えた例では、パフォーマンス（レイテンシーの観点から）が重要だと思います。つまり、株式相場表示が、株式の結果を最初に確認するために競合する株式ブローカーによって使用されている場合、.NETイベントのようなものと比較すると、WCF通信はおそらく失われます。
これは主に、私が理解しているように、WCFがクロスプロセス通信メカニズムとして設計されているという事実によるものです。これを実現するために、同じプロセスであっても、すべてのオブジェクトをシリアル化してから、データを別のプロセスにマーシャリングします。私はWCFを設定する方法を知らないので、同じプロセスに話しかけていることがわかります。
同じ.NETプロセスを使用している場合は、すべてのパブリックメソッドを直接呼び出すことができます。したがって、WCFを使用する場合とは対照的に、オブジェクトを直接使用する場合のオーバーヘッドははるかに少なくなります。