3

私は現在、以下の技術を使用するプロジェクトに取り組んでいます。

  1. ASP.netMVC-プレゼンテーション層
  2. データサービス層-（WCF）
  3. 自動マッパーを使用したデータ転送オブジェクト（DTO）レイヤー
  4. ドメインレイヤー（POCO、Code First Entity Framework）
  5. リポジトリレイヤー+EntityFramework 4.3+DbContext。

DTOを使用して、自動マッパーを使用してドメインオブジェクトを変換し、WCFサービスを使用してフロントエンドに送信します。

また、リクエストごとにWCFレイヤーでリクエストごとのDBContextを作成しており、WCFサービスコンテキストは、クライアント側のDTOでの呼び出しごとおよび追跡なしの有効化によって構築されており、完全に切断されています。

また、以下のオブジェクトグラフがあります。

public class User : BaseEntity
    {
        public virtual Identity Identity { get; set; }

        public string UserName { get; set; }

        public string Password { get; set; }

        public int IdentityId { get; set; }

        public virtual IList<Group> Groups{ get; set; }
    }



 public class Identity : BaseEntity
    {
        public string FirstName { get; set; }

        public string LastName { get; set; }

        public virtual IList<Email> Emails { get; set; }

        public virtual IList<PhoneNumber> PhoneNumbers { get; set; }
    }

私たちのDto構造は、ドメインと比較して同じです。

私の質問：

オブジェクトグラフを更新する場合例：UpdateUser（User user） ; Entity Frameworkの最良のアプローチは何ですか？

ここで、単一の関数を使用してナビゲーションデータを保存します。例：UpdateEmail（userId、Email）（関係ではなくプリミティブデータのみを保存します）。したがって、1つのUnitOfWorkを検討すると、データベースに多くの挿入と更新が行われます。

現在の実装は次のとおりです 

  public void UpdateUser(User user)
    {
    UpdateEmail(user.userId, user.Idenity.Emails);
    UpdatePhone(user.userId, user.Identity.PhoneNumbers);

    etc.............

    UpdateUser(user);
    UnitOfWork.Commit();// Calling DbContext.SaveChanges();
    }

オブジェクトグラフが切断されている上記の状況でEntityFrameworkで使用できるパターンまたはベストプラクティスはありますか？

4

3 に答える 3

10

それを解決するための多くのオプションはありません。EFには、切断されたオブジェクトグラフを更新するための直接的なサポートはありません。更新ロジックをコーディングする必要があります。これを行うには、通常2つの方法があります。

  • サービスリクエストから更新されたユーザーを受け取ると、データベースを呼び出し、現在のデータベースの状態=影響を受けるすべての関係を持つユーザーをフェッチします。データベースバージョンと更新されたバージョンを使用して有効な変更セットを構築するため、最後にEFは実際に変更されたデータのみを更新、挿入、および削除します。
  • DTOをトランスポート状態にも変更し、クライアントはDTOで行った変更の種類を設定する責任があります。この情報を使用ChangeTrackerして、受信したすべてのエンティティを正しく構成します。
于 2012-06-18T11:23:19.277 に答える
6

ジュリーラーマンはいくつかのビデオでこれを非常によく説明しています

于 2013-01-08T13:00:39.237 に答える
0

EFを使用していて、更新を何度も要求するようになった今、あなたの問題はありますか？あなたの電話番号と電子メールは別々のテーブルであるため、ここではそれを回避する方法がわかりません。それぞれの例を5つ含むユーザー用のフラット化されたエンティティを作成し、挿入用のprocにマップすることができます。それは電話を減らすでしょうが、最もきれいな私見ではありません。一度に多くのユーザーを処理している場合は、UOWを分割してユーザーごとにのみ動作するようにすることで、トランザクションを短縮できます。現在、パフォーマンスの問題がありますか、それとも将来の懸念がありますか？– </ p>

平坦化しないと、EFを使用しない場合と同じシナリオになります。DDDを使用しているため、データマッピングに固有のエンティティを導入できない理由がわかりません。エンティティは引き続き使用でき、さらにマッピングを備えた新しいエンティティがあります。実際、後でリポジトリ内のエンティティなしでこれを行うことができます（リポジトリは変更されたオブジェクトをクエリし、フラット化してデータアクセス層に送信し、procを呼び出します）

于 2012-06-18T14:34:27.543 に答える