1

DDD の有用性が EAV/CR に似ていると言うのは明らかに間違っていますが、これまでに見た唯一の違いは、3 つのテーブルと多数の結合ではなく、多数の結合を使用してエンティティごとに構築された物理テーブルです。

これは、私の DDD の理解不足によるものに違いありません。 データをインポートするときに、結合や複雑化を大幅に行わずに、これらのオブジェクトをデータベースに物理的に格納するにはどうすればよいでしょうか? リポジトリにフィードするオブジェクトを簡単に作成できることはわかっていますが、カスタム C# オブジェクトとフレームワークを使用するように Microsoft Sql Server Integration Server などのツールをトレーニングするのは困難です。おそらくそれが私の質問です。Microsoft SQL Server Integration Services および Report Services で DDD ASP.NET C# フレームワークをどのように使用しますか? 笑。

EAV/CR データベースでは、ベンダー、顧客、バイヤー、代表者、会社、用務員など、人のタイプに応じて異なるクラスを持つ単一の Person テーブルをセットアップできます。3 つのテーブル、いくつかの結合、属性は常に文字列です。オブジェクトが任意の値を受け入れますが、有効になるまで保持されない MVC の ModelValidation と同様に、挿入する前に検証します。

標準的なリレーショナル モデルでは、エンティティの種類ごとにテーブルを作成し、City などの冗長なデータ型を混在させていました。

ドメイン駆動設計を使用して、オブジェクトを使用してエンティティの各タイプを表し、ValueObject の各タイプにネストされたオブジェクトを使用し、必要に応じてさらにネストされたオブジェクトを使用します。私の理解では、これにより、エンティティの種類ごとにテーブルが作成され、情報セット (値オブジェクト) の種類ごとにテーブルが作成されます。これらすべてのテーブルで、多くの結合が見られます。また、新しい連絡先の種類ごとに物理テーブルを作成することになります。明らかにもっと良い方法があるので、オブジェクトをデータベースに永続化する方法が間違っているに違いありません。

私のベンダーは次のようになります。

public class Vendor {
    public int vendorID {get; set;}
    public Address vAddress {get; set;}
    public Representative vRep {get;set;}
    public Buyer vBuyer {get; set;}
}

私のバイヤー:

public class Buyer {
   public int buyerID {get; set;}
   public Address bAddress {get; set;}
   public Email bEmail {get; set;}
   public Phone bPhone {get; set;}
   public Phone bFax (get; set;}
}

Vendor.vBuyer.bPhone.pAreaCode のようなものを本当に参照していますか? Vendor.BuyerPhoneNumber を参照して保存し、Vendor.Address1、Vendor.Address2、Vendor.BuyerPhoneNumber などの部分のエイリアスのようにオブジェクトを作成すると思います。

4

4 に答える 4

1

オブジェクトを xml にシリアル化し、それを SQL Server の xml 列に保存できます。結局のところ、階層データ構造を表現しようとしており、それが xml の優れたところです。

于 2010-02-16T15:25:44.680 に答える
1

本当の答えは、SQL の正規化戦略をオブジェクトに合わせることです。重複するアドレスが多数あり、それらを関連付ける必要がある場合は、データを別のテーブルに正規化して、値オブジェクトが必要になるようにします。

于 2010-02-19T18:28:52.753 に答える
1

ドメイン駆動型設計の支持者は、データ モデルをできるだけオブジェクト モデルに近づけることを推奨することがよくありますが、これは鉄則ではありません。

オブジェクト リレーショナル マッピング レイヤーでマッピングを作成してデータをオブジェクトに変換 (投影) する場合は、EAV/CR データベース設計を引き続き使用できます。

オブジェクトを設計し、子の値へのアクセスを提供する方法を決定することは、実際には個別の問題であり、ケースバイケースで対処する必要があります。Vendor.BuyerPhoneNumberまたはVendor.vBuyer.bPhone.pAreaCode？答えは、特定の要件に根ざしているため、常に異なります。

于 2010-02-16T15:56:54.010 に答える