私はアプリケーションの設計に取り組んでおり、WCF サービスと ASP.NET Web アプリケーション間のデータの受け渡しについて調査しています。私が検討しているオプションは、「データセット」またはエンティティ フレームワークのいずれかを使用することです。
いろいろ質問がありますが、
全体として、これらのテクノロジを使用することの長所と短所を把握する必要があります。
あなたの質問は、サービス指向アーキテクチャ (SOA) の原則に触れています。SOA では、サービスは、コントラクトを通じてビジネス オブジェクトに適用される操作 (メソッド) を公開する必要があります。ビジネス オブジェクトは標準的な方法で定義する必要があるため、WCF は WSDL と XML スキーマを使用してこれを行います。
SOA の原則は、ビジネス オブジェクトはスキーマやコントラクトを通じて共有されますが、特定の実装としては共有されないというものです。この原則により、Dataset は重量のある .NET 固有のデータベース指向オブジェクトであり、ビジネス オブジェクトを表すために使用すべきではありません。Microsoft の Patterns & Practices グループは、データセットをデータ転送オブジェクトとして使用する方法を示しているため、明らかに SOA の原則を無視しています。彼らがベンダー ロックインを推進しているだけなのか、それとも SOA の概念全体を台無しにしているにすぎないのかは、誰にもわかりません。.NET 以外のクライアントがサービスを利用する可能性がほとんどない場合は、Dataset を使用しないでください。
Entity Framework を使用することに決めた場合は、Code Firstを使用して Entity Framework データ モデルを定義し、それらの "コード ファースト" ビジネス オブジェクトをサービスで公開することをお勧めします。このSO の質問と回答は、WCF での Entity Framework の使用に関する良い議論を提供します。
データセット全体を上下に渡すことを本当に考えていますか? リポジトリ パターンを実装できると思いますが、これはオブジェクト モデルを破壊し、維持するのがより困難になります。それでも、変更を送信するだけでも、スキーマを転送しないようにしたり、おそらく圧縮オプションを使用したりするなど、奇妙なことを行う必要があります。しかし、別のアセンブリにクリーンな POCO があり、EF インフラストラクチャが DTO を汚染していない Entity Framework Code First と比較すると、これは非常に悪い選択です。
EF 自体がオーバーヘッドを追加することはありませんが、実装方法と渡されるデータ オブジェクトによって異なります。SaveChangesデータをコンテキストに渡し、などの呼び出し時に正しいオプションを使用するとSaveChangesOptions.ReplaceOnUpdate、変更されたエンティティのみが更新されます。実行されるクエリは、必要のないものを遅延ロードしないように注意している限り、効率的です。エンティティへの LINQ をよく理解し、コストがかかる可能性のある他のメソッド呼び出しと同じように、更新をバッチ処理する必要があります。データベース プロファイラーを実行していくつかのテストを実行し、EF とのやり取りの効率を向上させたり、IIS ログのデータ サイズや送信時間などを監視したりします。
スキーマをカプセル化する必要があるため、データセットは軽量とは見なされず、誰かが間違いを犯して、依存関係にあるテーブルを含む複数のテーブルにデータのヒープ全体を送信する可能性があります。これらは、クライアントまたはサーバーのいずれかでとにかくプルする必要がある場合があります-非常に面倒です! EF は、ストアド プロシージャをモデルの一部にすることができ、特定のエンティティを保存する必要があるときに呼び出されるため、賢明な方法でストアド プロシージャをサポートします。ORM は OO 設計を補完し、よりクリーンなコードに導きます。
また、何か単純なことを行っていて、ビジネス ロジックをあまり必要とせずに CRUD のみを必要とする場合は、WCF Data Services を検討してください。