-1

私は EF Code First と遅延読み込みを使用します。

私の問題は、孫コレクション内のエンティティを効率的に更新する方法に関連しています。まず第一に、これにより、実際には必要のないデータベースで多くの呼び出しが行われるのではないかと心配しています。しかし、私のドメイン クラスが持続性を気にしないのであれば、これを行う別の方法が思い浮かびません。

クラスは次のとおりです。

  public class Supplier
 {
  public int Id {get;set;}
  //...Supplier properties

  public virtual ICollection<Contract> Contracts {get;set;} 

  //supplier methods   
 }

 public class Contract
 {
  public int id {get;set;}
  public int SupplierId{get;set;}
  //---Contract properties

  [ForeignKey("SupplierId")]
  public virtual Supplier Supplier {get;set;}
  public virtual ICollection<DeliveryContract> DeliveryContracts {get;set;} 
 }

 public class DeliveryContract
 {
  public int Id {get;set;}
  public bool DeliveryOnMonday{get;set;}
  public bool DeliveryOnTuesday{get;set}
  //...30 different Delivery terms properties

  public Department Department {get;set;}

  public int ContractId {get;set;}
  [ForeignKey("ContractId")
  public virtual Contract Contract {get;set;}
 }

サプライヤーは集約ルートです。だから私は ChangeDeliveryContract であるサプライヤーにメソッドを持っています、そしてそれは現実の世界で起こることに対応しています。

public class Supplier
{
 //properties

 public void ChangeDeliveryContract (DeliveryContract cahangedDc)
 {
   //So from the supplier i have to find the contract to change
   var dcToUpdate = Contracts
                    .SingleOrDefault(c=>c.Id == changedDc.ContractId)
                    .SingleOrDefalut(dc=>dc.Id == changedDc.Id);

   //So... what do i do now? Map all 30 properties from changedDc to DcToUpdate
   //Some business rules is also applied here i.e. there can only be one
   // DeliveryContract between Supplier and Department
 }
}

私は MVC を使用しているので、プログラムは次のようになります。

{
  var Supplier = supplierRepository.GetById(supplierid);
  supplier ChangeDeliveryContract (changedDc);
  supplierRepository.Save();

  //More code...
}

まず第一に、問題は ChangeDeliveryContract にあります。私はこれを機能させることができませんでした。また、私のようにコレクションを照会するのは非効率的かもしれません。第 3 に、30 以上のプロパティをマッピングするのも少し間違っているように感じます。

皆さんはどのようにそれを行いますか、そしてここにベストプラクティスはありますか?

4

3 に答える 3

1

OK、これは少し紛らわしいです。ドメインモデルと永続性モデルが混在していると非難します（ええ、これらのEFチュートリアルは、すべての人を混乱させる素晴らしい仕事をしました）。ある人が別の人に影響を与えるべきではないので、リポジトリパターンがあります。そして、はい、ドメインは永続性を気にするべきではありません。

サプライヤはEFについてもう知らないので、見てみましょう...私が正しく理解している場合は、ビジネスルールを考慮する必要があるため、サプライヤ（およびおそらく子の骨材も）を再設計する必要があります。 。

そのコードから要件をリバースエンジニアリングするのはかなり難しいですが、サプライヤーはさまざまな部門に配送契約を結んでいるように感じます。配信契約を変更する場合、サプライヤはそのコンテキストで有効なビジネスルールを適用する必要があります（同じエンティティに有効なコンテキストが複数ある場合は重要です）。

納品契約はもう少し明確にする必要があると思いますが、それは30のプロパティしか持たないダムオブジェクトだけだとは信じられないからです。おそらく、いくつかのビジネスルールはいくつかのプロパティに関連付けられていますか？したがって、詳細が必要です。

余談ですが、実際に30のプロパティをマップする必要がある場合は、その方法でAutomapperを使用できます。

于 2012-03-02T15:10:23.143 に答える
1

ChangeDeliveryContract のプロパティ マッピングについて、30 個のプロパティをマッピングするのは少し間違っているように感じます。30 個のプロパティをマッピングすること自体には何の問題もありません。やらなければならないなら、やらなければならない。AutoMapper を使用して、タスクを容易にすることができます。

「Supplier.MakeDeliveryOnMonday()」、「Supplier.DontMakeDeliveryOnTuesday()」などのメソッドを作ると、コードの「感触」が変わると思います。おそらく、これらのメソッドが何をするかは推測できます (ビジネス ロジックを確認し、ブール値を true または false に設定します)。そのため、ChangeDeliveryContract のような「大きな」メソッドを使用する必要はありません。

于 2012-03-27T09:59:13.880 に答える
1

DDD を適用する場合、集約ルートの選択は、モデルのさまざまな特性 (子の数に関する考慮事項など) によって異なる場合があります。この場合、Supplier は AR ですが、DeliveryContract もできないという意味ではありません。 ARになる。サプライヤが唯一の AR であり、サプライヤに関するすべての操作はサプライヤ クラスから派生する必要があるように思えるかもしれませんが、これは、データベース呼び出しに関しては手に負えない場合があることを認識してください。AR の役割の 1 つは不変条件の保護であり、不変条件の保護に使用されるサプライヤー クラスには何もありません。これは、サプライヤーが必要なビジネス ルールを実装するのに最適な AR ではないことを示している可能性があります。したがって、この場合、DeliveryContract を独自のリポジトリと変更を適用する方法を備えた AR にすることができるように思えます。または、コントラクトが配信コントラクトに関する不変条件を強制する必要があるかどうか、およびコントラクトごとに予想される配信コントラクトの数の実際的な考慮事項に応じて、コントラクトを AR にすることができます。数が非常に多い場合、契約クラスで配送契約のコレクションを持つことは実際的ではありません。全体として、不変条件と一貫性ルールを考慮する必要がありますが、AR を小さくすることを選択します。

このトピックの詳細については、Vaughn Vernon による優れた一連の記事を参照してください:効果的な集合体の設計。

于 2012-03-03T01:42:25.727 に答える