私はEFが最初に登場したときから使用しています。以前は 3.5 で POCO を手作業で構築していましたが、EF4.0 で Self Tracked Entities (STE) を確認できてうれしく思いました。
私はいくつかの非常に大規模なプロジェクト (500 以上のエンティティ、複数のモデルを持つもの) で STE を使用しています。これらのプロジェクトでは、一般的なリポジトリと一般的な作業単位を使用してエンティティを永続化します。つまり、2 つの小さな一般的なクラスはマッピングされません。コア エンティティを「集約ルート」として選択することにより、他のエンティティがクライアント側で追加および更新され、これらの変更を含むコア エンティティ グラフが WCF サービスに送信され、リポジトリを作成するロジック レイヤーで使用されます<[コア エンティティ]> を使用し、UnitOfWork<[core entity]>.Save(Repository<[core entity]>) を使用して、STE とその子をデータベースに永続化します。
現在、Microsoft は STE を使用しないことを推奨しています。この記事を見る
私の質問は、EF を使用する WCF サービスへのクライアントの変更を永続化するアプリケーションに対して Microsoft が現在推奨しているパターンは何ですか?
EF5 モデルを作成し、生成されたコードを調べました。WCF サービス、つまり DataContract、DataMember などの属性はありません。
EF4 には "ADO.NET DbContext Generator with WCF Support" テンプレートがありましたが、EF5 に相当するものはありません。
あるサイトでは、部分クラス ファイルを使用し、そのファイル内の同じプロパティをこれらの属性で装飾することを提案しました。しかし、.net 4.5 で部分的なプロパティが導入されていない限り、それを行う方法がわかりません。
別の ブログ では、DTO と Automapper の使用を提案しています。これは、エラーが発生しやすいマッピングが増えることを意味します。特にエンティティ フィールドのタイプが変更された場合。
したがって、DBContext によって生成されたコード クラスは Service 対応ではありません。これは、次のような別のクラス セット (POCO) を作成する必要があることを意味します。
- データベースにクエリを実行した後、DBContext で生成されたコード クラスからマップする必要があります。
- WCF サービス クライアントのデータ状態を保持します
- そのクライアントによって更新可能です
- クライアントによってマップされます
- 変更された状態を保持する機能があるため、これを WCF サービスに送り返すことができます
- 永続性のために、DBContext によって生成されたコード クラスにマップする必要があります。
EF3 に向けて大きく後退したようです。
ハードウェア上で実行されるクライアントとサービスの両方をコーディングする場合、クライアントのデータ構造は自分のものであるため、気にする必要はありません。
サービス メソッドの一部を .NET 以外のクライアントにも公開する必要がある場合は、これらのサービスに対して上記の 5 つのポイントを実行し、その場合は DTO と Automapper を使用する必要があります。これらは別の WCF サービスにある必要がありますが、同じロジックに対して実装する必要があります。レイヤー、マッピング後。
しかし、ほとんどのソフトウェア チームが Web アプリケーションを日々構築する中で、これらのタイプの非 .NET クライアント サービスがいくつ作成されているでしょうか?
この最新の推奨事項は、STE が常に間違った考えである理由と、EF を使用する WCF サービスへのクライアントの変更を永続化するために使用する推奨パターンについて説明されていないため、混乱を招きます。
このアーキテクチャ設計の問題を解決する優れたリソースがどこにあるか教えてもらえますか?
PS
クライアントがデータを取得および保存する方法を細かく制御する必要があるため、WCF Data Services や WCF RIA はお勧めしません。
Code First はお勧めしません。Database First を使用するのは、そのデータベースの構造を必要とし、制御する必要があり、生成する必要がないからです。