ADO.NetDataServicesについて少し混乱しています。
これは、RESTful Webサービスを作成するためだけのものですか？WCFがSOAPの世界で始まったことは知っていますが、今ではRESTを適切にサポートしていると聞いています。リソース指向のビューからすべてを見ることができない場合にRPCモデルで機能させることができるADO.Netデータサービスについても同じことが言えます。
少なくとも最近見たデモからは、ADO.NetDataServicesがサーバー上のWCFスタック上に構築されているように見えます。私が間違っている場合は訂正してください。
私はRESTとSOAPの議論を始めるつもりはありませんが、物事はもはやそれほど明確ではないと思います。
何をどこで使用するかについての提案やガイドラインはありますか？
私の見解では、ADO.Netデータサービスは、ドメインモデルと緊密に連携するRESTfulサービスを作成するためのものです。つまり、モデル自体は、何らかの形式のDTOなどではなく公開されます。
RPCスタイルのサービスに使用するのは適切ではないようですが、残念ながら、フィルター処理されたカウントを実行できるなどの非常に基本的な機能でさえ利用できないため、RPCを使用して次の要件を満たすことになります。つまり、ページグリッドなどを表示できるようになります。
WCF 3.5 pre-SP1はかなり弱いRESTfulプラットフォームであり、SP1の機能はUriテンプレートとATOMPubサポートの両方で改善され、より機能的になりましたが、JSONなどをサポートするためのエレガントなソリューションは実際には提供されていません。 、XML、ATOM、またはCSVのようなペイロードのようなより難解なものを同時に使用します。ただし、URLの書き換えや異なる拡張子、メソッド名の変更などを使用する必要はありません。リクエストのヘッダーに基づいてシリアライザー/デシリアライザーを選択するだけではありません。
WCFを使用すると、より自然な安らかなマナーで機能するサービスを作成することは依然として困難です。つまり、リソースにURLが含まれている場合、URLをナビゲートすることで状態を移行できます。これは、少し不格好です。ADO.Netデータサービスは、AtomPubを使用してこれを非常にうまく実行します。ただし、サポートします。
私の推奨事項は、当然のことながらサービスであり、強力なサービス境界が適用されているWebサービスを使用することです。また、URLクエリの構成可能性によって節約できるリッチWebスタイルのクライアント（Webサイト、ajax、silverlight）にはADO.Netデータサービスを使用することをお勧めします。多くの配管とドメインモデルは非常に基本的です...情報を完全に制御する必要がある場合、つまり他の開発者向けにAPIを公開している場合は、独自のRESTレイヤーをロールします（おそらく開始点としてMVCフレームワークを使用します）。ソーシャルプラットフォームなどで消費します。
私の2øの価値！
WCFのRESTバインディングを使用することは、データベースとまったく対話しないコードを操作する場合に非常に有効です。HTTP動詞は、必ずしもデータプロバイダーに対抗する必要はありません。
実際には、とりわけページのような機能を取得するためにフィルタリングおよびスキップするオプションがあります。