WCFは基準を引き上げますか、それとも単に複雑さのレベルを引き上げますか？[閉まっている]

WCFが提供する3つの部分からなるサービス/ホスト/クライアントモデルの価値を理解しています。しかし、それは私だけですか、それともWCFがかなり直接的で単純なもの（ASMXモデル）を取り、それを台無しにしたように見えますか？

SvcUtilのコマンドラインを過去にさかのぼってプロキシを生成する代わりの方法はありますか？ASMXサービスでは、テストハーネスが自動的に提供されました。今日、WCFに良い代替手段はありますか？

WS *のものがWCFとより緊密に統合されていることを感謝し、そこでWCFの見返りを見つけたいと思っていますが、それ以外の場合は困惑しています。

また、WCFで利用できる本の状態はせいぜいひどいものです。優れた著者であるJuvalLowyは、優れたO'Reillyの参考書「ProgrammingWCF Services」を作成しましたが、WCFの使用法を学ぶために（とにかく）それほど多くのことをしていません。その本の前身（そしてチュートリアルとしては少しよく整理されていますが、それほど多くはありません）は、Michele LerouxBustamanteのLearningWCFです。良い場所がありますが、場所が古く、対応するWebサイトがなくなっています。

物事からベジェバスをグーグルで続ける以外に、良いWCF学習リファレンスがありますか？

さて、ここに行きます。まず、ミケーレ・ルルー・ブスタマンテの本がVS2008用に更新されました。その本のウェブサイトはなくなっていません。それは今アップしていて、それはたくさんの素晴らしいWCF情報を持っています。そのウェブサイトで、彼女は自分の本のすべての例について、VS2008と互換性のある更新されたコードを提供しています。アマゾンに注文すると、更新された復刻版が届きます。

WCFは、ASMXの代わりになるだけではありません。確かにASMXを置き換えることができます（そして非常にうまく機能します）が、本当の利点は、サービスをセルフホストできることです。WSEの機能のほとんどは、最初から組み込まれています。フレームワークは高度に構成可能であり、複数のプロトコルを介して複数のエンドポイントにサービスを提供する機能は驚くべきものです、IMO。

[サービス参照の追加]オプションからプロキシクラスを生成することはできますが、必須ではありません。あなたが本当にしなければならないのは、ServiceContractインターフェースをコピーして、サービスのエンドポイントを見つける場所をコードに伝えることだけです。それだけです。非常に少ないコードでサービスからメソッドを呼び出すことができます。この方法を使用すると、実装を完全に制御できます。プロキシクラスを生成するために選択した方法に関係なく、ミケーレは両方を示し、この主題に関する彼女の優れた一連のWebキャストで両方を使用しています。

ミケーレにはたくさんの素晴らしい資料があります。彼女のウェブサイトをチェックすることをお勧めします。WCFを学んでいたときに、私にとって非常に役立つリンクをいくつか紹介します。WCFが実際にどれほど強力であり、実装がいかに簡単であるかを理解していただければ幸いです。学習曲線は少し急ですが、時間の投資に対する見返りはそれだけの価値があります。

• ミケーレのウェブキャスト：http：//www.dasblonde.net/2007/06/24/WCFWebcastSeries.aspx
• ミケーレの本のウェブサイト（VS2008用に更新されています）：http：//www.thatindigogirl.com/

ミケーレのウェブキャストを少なくとも1つ視聴することをお勧めします。彼女は非常に効果的なプレゼンターであり、WCFに関しては明らかに非常に知識が豊富です。彼女は、WCFの内部動作をゼロからわかりやすく説明する素晴らしい仕事をしています。

私は通常、Googleを使用してWCFの回答を見つけ、次のブログで自分自身を見つけるのが一般的です。

貴重なWCF記事のあるブログ

• http://blogs.msdn.com/drnick/default.aspx
• http://blogs.msdn.com/wenlong/default.aspx
• http://blogs.thinktecture.com/buddhike/
• http://www.dasblonde.net/default.aspx

私が見つけた他の貴重な記事

• http://blogs.conchango.com/pauloreichert/archive/2007/02/22/WCF-Reliable-Sessions-Puzzle.aspx
• http://blogs.msdn.com/salvapatuel/archive/2007/04/25/why-using-is-bad-for-your-wcf-service-host.aspx

WCFをいつ使用するか、または使用するかを確認するのに苦労しています。どうして？生産性とシンプルさをリストの一番上に置いているからです。ASMXモデルがうまく機能し、高速に動作するようになったのはなぜですか。そして、VS2005と.NET2.0では、wsdl.exeは非常に優れた準拠サービスを吐き出していました。

実際には、アーキテクチャに含まれる通信プロトコルはごくわずかです。これにより、メンテナンスが簡単になります。レガシーシステムにアクセスする必要がある場合は、それらに固有のアダプターを作成して、光沢のある美しいSOAの世界で一緒にプレイできるようにします。

WCFはASMXよりもはるかに強力であり、いくつかの方法で拡張されます。ASMXはHTTPのみに制限されていますが、WCFは通信に複数のプロトコルを使用できます（もちろん、HTTPは、少なくとも相互運用性が必要なサービスでは、ほとんどの人が使用する方法です）。WCFも拡張が簡単です。少なくとも、ASMXを拡張できない方法で拡張することは可能です。「簡単」はそれを伸ばしているかもしれません。=）

私の意見では、WCFによって提供される追加機能は、WCFが追加する複雑さをはるかに上回っています。また、プログラミングモデルの方が簡単だと感じています。たとえば、DataContractsは、すべてのパブリックプロパティを使用してXMLシリアル化を使用してシリアル化するよりもはるかに優れています。また、本質的にはるかに宣言的であり、これも素晴らしいことです。

待ってください..... NET Remotingを使用したことがありますか？それが本物の代わりになります。.NETRemoting自体はかなり複雑です。WCFの方が簡単で、レイアウトも優れていると思います。

十分な頻度で言及されているとは思いませんが、ASMXサービスと非常によく似た、かなり単純なサービスをWCFで実装できます。例えば：

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class SimpleService
{
    [OperationContract]
    public string HelloWorld()
    {
        return "Hello World";
    }

}

web.configにエンドポイントを登録する必要がありますが、それほど悪くはありません。

分離されたデータ、サービス、および運用契約の冗長性を排除することは、WCFをより管理しやすくするのに大いに役立ちます。

VS2008には、バックグラウンドでプロキシを作成する「サービス参照の追加」コンテキストメニュー項目が含まれています。

前述のように、WCFは、ASMX Webサービスタイプの代替としてのみ意図されているのではなく、HTTP、tcp、名前付きパイプ、MSMQトランスポートのいずれを介する場合でも、すべての相互運用可能なサービスに一貫性のある安全でスケーラブルな方法を提供します。

私はWCFに他の問題があることを告白します（たとえば、basicHTTPを介してサービスを公開するときにメソッド署名を書き直す-ここを参照してください、しかし全体的にはそれは間違いなく改善だと思います

VS2008を使用してWCFプロジェクトを作成している場合は、run / debugを押すと自動的にテストハーネスを取得し、svcutilを使用せずに参照を追加できます。

WCFについての私の最初の考えはまったく同じでした！ここにいくつかの解決策があります：

1. ジェネリックスを利用して独自のプロキシ/クライアント層をプログラムします（クラスClientBase、Bindingを参照）。これは簡単に機能しますが、完璧にするのは難しいと思います。
2. 1のサードパーティ実装を使用します（SoftwareIsHardworkが私の現在のお気に入りです）

WCFは、Microsoftの以前のすべてのWebサービステクノロジに代わるものです。また、従来「Webサービス」と見なされていたものよりもはるかに多くのことを行います。

WCFの「Webサービス」は、WCFを介して可能になるはるかに幅広いリモート通信の一部です。WCFは、マイクロソフトが提供するさまざまな分散プログラミングインフラストラクチャをすべて要約するようにゼロから設計されているため、従来のASMXよりもWCFで作業を行う際の柔軟性と移植性が大幅に向上します。WCFのエンドポイントは、TCP /バイナリを介した場合と同じようにSOAP / XMLを介して簡単に通信でき、このメディアを変更するには、構成ファイルのmodを使用するだけです。理論的には、これにより、ビジネスニーズ、ターゲットなどを移植または変更するときに必要な新しいコードの量が削減されます。

ASMX is older than WCF, and anything ASMX can do so can WCF (and more)。基本的に、WCFは、Microsoftの世界で2つのアプリを通信させるためのさまざまな方法をすべて論理的にグループ化しようとしていると見なすことができます。ASMXは、これらの多くの方法の1つにすぎなかったため、現在はWCFの機能の傘下にグループ化されています。

WebサービスにはHTTP経由でのみアクセスでき、ステートレス環境で機能します。WCFは、さまざまな種類のアプリケーションでサービスをホストできるため、柔軟性があります。WCFサービスをホストするための一般的なシナリオは、IIS、WAS、セルフホスティング、マネージドWindowsサービスです。

主な違いは、WebサービスがXmlSerializerを使用することです。ただし、WCFはXmlSerializerと比較してパフォーマンスが優れているDataContractSerializerを使用します。

どのシナリオでWCFを使用する必要がありますか

• 商取引を処理するための安全なサービス。そのサービス
• トラフィックレポートやその他など、現在のデータを他のユーザーに提供します
• 監視サービス。2人でできるチャットサービス
• リアルタイムでデータを通信または交換します。ダッシュボードアプリケーション
• 1つ以上のサービスをポーリングしてデータを取得し、論理的に表示します
• プレゼンテーション。Windowsワークフローを使用して実装されたワークフローの公開
• WCFサービスとしての基盤。ポーリングするSilverlightアプリケーション
• 最新のデータフィードのサービス。

WCFの機能

• サービス指向
• 相互運用性
• 複数のメッセージパターン
• サービスメタデータ
• データ契約
• セキュリティ
• 複数のトランスポートとエンコーディング
• 信頼性の高いキューに入れられたメッセージ
• 耐久性のあるメッセージ
• トランザクション
• AJAXとRESTのサポート
• 拡張性

ソース：テキストの主なソース

MSDN？私は通常、ライブラリレファレンス自体でかなりうまくやっており、貴重な記事がそこにあることを期待しています。

それが提供するものに関しては、答えは互換性だと思います。ASMXサービスはかなりマイクロソフトでした。彼らが他の消費者との互換性を保とうとしなかったと言っているのではありません。しかし、このモデルは、ASP.NETWebページやその他のカスタムMicrosoftコンシューマー以外にはあまり適合していませんでした。一方、WCFは、そのアーキテクチャにより、通常のSOAPに加えて、REST、JSONなどの非常にオープンスタンダードベースのエンドポイントを持つことができます。他の人はおそらく、ASMXサービスよりもはるかに簡単にWCFサービスを利用できるでしょう。

（これは基本的にMSDNの比較資料から推測されるため、詳細を知っている人は遠慮なく私を訂正してください。）

WCFはASMXの代わりと考えるべきではありません。それがどのように配置され、Microsoftによって内部的にどのように使用されているかを判断すると、これは実際には、あらゆるタイプの境界を越えた通信に使用される基本的なアーキテクチャです。

WCFは、ASMXWebサービスの実装をさまざまな方法で実際に進歩させていると思います。まず第一に、分散アプリケーションの本質的な複雑さを隠すのに役立つ非常に優れたレイヤードオブジェクトモデルを提供します。第2に、サーバーからクライアントへの非同期通知（純粋なHTTPでは不可能）を含むリクエストリプレイメッセージングパターン以上のものを使用できます。第3に、基盤となるトランスポートプロトコルをXMLメッセージングから抽象化して、HTTP、HTTPS、TCPなどをエレガントにサポートします。「第1世代」のWebサービスとの下位互換性もプラスです。WCFは、内部表現形式としてXML標準を使用します。これは、特にJSONのような「XMLの無脂肪の代替手段」の人気が高まっていることから、長所または短所として認識される可能性があります。

WCFで私が見つけた難しいことは、クライアントとサーバーの構成を管理し、それほど良くない障害状態の例外をトラブルシューティングすることです。

誰かがそれらのためのショートカットやヒントを持っていれば素晴らしいでしょう。

それは苦痛だと思います。両端に.NETがあり、両端に同じ「コントラクト」dllがロードされているなどです。しかし、「KnownType」属性などの多くの詳細をいじる必要があります。

また、WCFは、多くの構成を変更するまで、デフォルトで1つまたは2つのクライアントのみがサービスに接続できるようにします。コードから構成を変更するのは簡単ではありません。アップグレード時に顧客が行った可能性のある変更に変更をマージするのは非常に難しいため、大量のcomfigファイルを出荷することはできません（また、顧客を望まない） WCF設定で遊んでください！）

.NET Remotingは、ほとんどの場合機能する傾向がありました。

.NETから.NETへのオブジェクトベースの通信は、テキスト（xml）のビットを未知のシステムに送信するのと同じであると偽ってみるのは、一歩遠すぎたと思います。

（WCFを使用してJavaシステムと通信したことが数回ありましたが、Javaシステムが提供したXSDは、とにかく必要なXMLと一致しないため、多くのXMLマッピングを手動でコーディングする必要がありました。）