0

CartLine とその他の情報を使用して、複雑な「読み取りモデル」(カート) を作成する必要があります。現時点では、他の多くのオブジェクト (カート、操作など) に基づく ViewModel があり、このオブジェクトを構築するロジックは、リポジトリとコントローラー (集約ではありません) にディスパッチされています。 「読み取りモデル」を直接返すリポジトリ (フォーマットされたテキスト、価格など)。

Dapper ではストアド プロシージャ (クライアントのポリシー) のみを使用できます。この読み取りモデルを作成するより良い方法を探しています:

1.既存のストアド プロシージャを呼び出し、ストアド プロシージャの結果を DTO にマップし、その結果を読み取りモデルに再度マップします。

public class Cart
{
    public Cart(CartDb cartDb, IEnumerable<CartDetailDb> cartDetailsDb, 
                                                      OperationDB operationDb)
    {
        //Code
    }
}

-> 2 つのレベルのオブジェクトがあり、混乱していると思います

2.読み取りモデルに直接マップするストアド プロシージャを作成します (DTO を回避するため)。

-> ストアド プロシージャに何らかのロジックを追加する可能性があるため、この方法は好きではありません

3.ViewModelを使う

他の提案？

4

1 に答える 1

1

私の理解が正しければ、このエンティティのデータ モデルは、このエンティティのドメイン モデルと正確に一致していませんRead。また、中間の DTO レイヤーを必要とせずに、リポジトリ レイヤーから のドメイン モデルバージョンを直接返すこともできます。Read

私の意見では、オプション #1が最も理にかなっています。データ モデルとドメイン モデルの間にはインピーダンスの不一致があるため、2 つのモデル間でデータを変換するには、どこかにマッピング ロジックが必要になります。このロジックの最も適切な場所は、リポジトリ レイヤー内です。このレイヤーの全体的な目的は、ドメインとその永続性の間でオブジェクトをマッピングすることだからです。

これは、ストアド プロシージャからマップするために DTO レイヤーを作成する必要があるという意味ではありません。データ アクセス層から返された結果セットに対して変換ロジックを直接実行し、それを 1 つのステップでドメイン オブジェクトに変換するだけです。

データ アクセスの場合、DTO の必要性は、データ アクセスに使用しているテクノロジによって大きく異なります。たとえば、ADO.net ライブラリ ( 、 など) を使用している場合SqlCommand、SqlConnectionDTO はおそらく必要ありません。ただし、Entity Framework や NHibernate などの ORM を使用している場合は、これらのツールによって生成されたオブジェクトを厳密に DTO として使用し、本格的なドメイン オブジェクトにマップすることが理にかなっています。もちろん、これらのオブジェクトは自動的に生成されるため、DTO レイヤーを使用することによるメンテナンスの問題はほとんどなくなります。

これは、データ層がドメイン モデルと完全に一致する結果セットを返すようにするために、ストアド プロシージャに変換ロジックを配置する必要があるという意味でもありません。あなたが言ったように、私はこれを絶対に避けます。これにより、ドメインロジックがデータベースに配置されます。

最後に、ドメイン オブジェクトは価格などの「書式設定されたテキスト」で構成されていると述べています。ほとんどの場合、テキストの書式設定は実際には UI レイヤーの一部であり、ドメイン モデルではありません。つまり、モデルに などのプロパティがある場合、通貨として書式設定された ではなくまたはPriceとして表す必要があります。つまり、値は"$5.00" ではなく5.00にする必要があります。 DoubleDecimalString

このようなフォーマット変換を処理するには、ドメイン オブジェクトをViewModel前述のようなものでラップして、ドメインから UI レイヤーへの変換を処理するのが適切です。このような状況で厳密な分離の懸念事項を使用すると、保守が容易な、より堅牢なシステムを作成するのに役立ちます。

于 2012-09-18T17:20:01.850 に答える