Silverlight アプリケーションがサーバーに接続するには、さまざまな方法があります。含む
これらのそれぞれについて、その用途と、いつ使用するか、または使用しないかを述べてください. 私は、それらの中から選択するための一連の「経験則」だけを探しているわけではありません。
(問題は、最初の Silverlight アプリケーションを設計するときに、すべてを学習する時間がないときに何を使用するかを知っていることです。)
この質問で Silverlight を WPF に置き換えるとしたら、回答にどのような影響がありますか? (WPF では、ファイアウォールと管理ポリシーにより、データベースへの直接接続はオプションではないと想定しています。)
私の2（ユーロ）セント：
WCFは、サービスをアプリケーションのビジネス レイヤーと見なすことができる場合、つまり、サービスに"CalculateDiscountForClient"のような "インテリジェントな" 操作がある場合に最適と思われます。
ADO.NET Data Services (実際には単なる REST 実装) は、アプリケーションが基本的にデータ中心であり、サービスがデータベースの単なるフロントエンドである場合に適しているようです。つまり、すべてのサービス メソッドはGetCustomers、CreateInvoiceなどのタイプです。
RIA サービスは非常に新しいテクノロジであり、私はまだ試していませんが、Silverlight 部分とサービスが非常に緊密に結合されたアプリケーションを作成すると便利なようです。サービス プロジェクトでサービス クラスとメソッドを定義し、また、設計時に Silverlight プロジェクトに自動的にレプリケートされます。また、WCF スタイルの「アクション」メソッドと ADO.NET Data Services スタイルの「データ」メソッドの両方を定義できます。有望に見えます。
将来、クライアント部分を Silverlight から他のテクノロジ (HTML+AJAX など) に変更する可能性がある場合は、POXを使用してください。POX は最も相互運用性の高いオプションです。
WPFの違いについて、私が考えることができる唯一のことは、可能な限り、ADO.NETの代わりに直接ADO.NETデータ接続（データアクセスレイヤー、LINQ to SQLなどに適切に埋め込まれている）を使用することです。 Data Services の方が柔軟性が高いためです。とにかく、私は WPF で何も開発したことがないと言わなければなりません。
私たちはRIAを使用しており、それが私が知っている唯一のオプションですが、私はそれを知っているので、ここに私の考えのいくつかがあります。
RIAはまだ完成していません。作業中です。すぐに終了することを計画していて、かなり変更される可能性のあるものをサポートする必要があることを心配している場合は、他のオプションを検討することをお勧めします。これが新しいプロジェクトであり、長期間サポートする予定の場合、RIAはおそらく使いやすくなります。
そうは言っても、RIAの7月のプレビューの動作と完成したバージョンの動作にはそれほど変更はないと思います。また、サポートのレベルは、これがSilverlightのサーバーと通信するための「方法」になることを示唆しているようです。
言及する価値があるという理由だけで、いくつかのリンクがあります：
http://blogs.msdn.com/brada/ Brad Abramsには、彼が継続的に更新している例があります。
http://forums.silverlight.net/forums/53.aspxここで質問をします。
http://www.riaservicesblog.com/Blog/ Colin Blairは自分のことを知っており、非常に役に立ちます。
私は二度とPOXに行かないと思います。サービス自体がバインディングに依存せず、バインディングが構成ファイルで行われるように WCF を作成すると、WCF はトランスポートとプロトコルにほとんど依存しなくなります。SOAP、JSON、REST、または独自の形式のバイナリ シリアル化を実行できます。これらはすべてバインディングにあります。内部的には、WCF は、操作とデータ コントラクト (すべてクラス、メソッド、およびプロパティ属性によって定義されます) に関して公開されるもののみを指定します。WCF は、この点に関して非常に柔軟であり、2010 年にはさらに多くの機能が提供される予定です。
Silverlight 側から見ると、WCF では配管コードを記述する必要があります。.NET フレームワークには、Silverlight プロジェクトでプロキシを構築するためのツールがありますが、すべての WCF 応答を非同期で処理する準備ができている必要があり、プロキシはサービスによってスローされた例外をキャッチできません。
.NET RIA サービスは、これらすべてを隠します。内部では WCF を使用していますが、それは完全に隠されています。非同期コードを記述する必要はありません。ほとんどの場合、検証を一度定義すると、サーバー側とクライアント側の両方で機能します。リリース 1 は Silverlight を対象としているため、このサービスを他の場所で使用するための汎用性は得られません。その範囲は、以降のリリースで拡大される予定です。
ADO.NET Data Services については、比較するのに十分な知識がありません。答えは、Silverlight の使用以外にデータを公開するかどうかによって異なると思います。
.NET RIA Services は、私が行きたい方向性のように見えます (大規模なアプリケーションを念頭に置いて、これらの問題を自分で調べています)。私にとっての大きな問題は、サービス層に非常に大きな機能のコレクションを実装することと、データ アクセス層に直接コーディングできないことです (SQL Server または Oracle のいずれかで実行できる必要があります)。
Silverlight の代わりに WPF を使用すると、データが存在する場所に応じてすべてが変わります。これは、Winforms と ASP.NET の古い問題のようなものです。WPF を使用すると、Windows クライアント アプリを作成できます。データ アクセスによって強制されない限り、サービス ベースのデータ インターフェイスを使用する必要はまったくありません。MVVM、MVC、または MVP を使用して、データとビジネスをプレゼンテーション コードから分離する必要があります。それ以外に、データ アクセスを完全に独立した層ではなく、層として扱うオプションがあります。
WCF は、Microsoft のサービス通信の標準です。2012 年 4 月にリリースされる WCF Web API (WCF を使用しますが、REST 用に特別に調整されています) を使用してサービス層を作成することを強くお勧めします。WCF Web API は現在プレビュー モードです。
これらの経験則を覚えておいてください: - UI は、サービス層よりも速く変化します。RESTful サービスは数年以内に登場しますが、Silverlight はおそらくそうではないでしょう。サービスが API になることはありますか? ええと...WCF REST が進むべき道です。JavaScript と Silverlight コードを混在させますか? WCF REST はあなたの生活を楽にします - モバイル コンポーネントはありますか (Silverlight は iOS や Android では動作しないため)... REST が推奨されます。
テクノロジーに合わせて調整するのではなく、アプリ全体に合わせて調整してください。
Silverlightアプリケーションを作成したいが、他のクライアントを気にしない場合は、RIAサービスを選択します。使用するのは非常に簡単で、クライアントからの接続がどのように行われるかを心配する必要はありません（つまり、クライアント側の構成は必要ありません）。RIAは、クライアント上のすべてのエンティティのクラスも生成します。必要に応じて、独自の「サーバー」コードをクライアントと共有することもできます（列挙または拡張メソッドに役立ちます）。
備考：