1

私は次のデザインを持っています： 私のデザイン 私のデザインhttp://s15.postimg.org/3zha8rzqh/Design_Idea.png

サービスレイヤー（左側のサービス）に「ProductDTO」というクラスがあります。

「製品の更新（ProductDTO）」操作コントラクトが呼び出されると、ビジネスロジックレイヤーの「製品の更新」関数を呼び出す必要があります。

データベース（「データアクセス層」）には「Product」というエンティティがあり、LINQ-To-Entitiesを使用しているため、「Product」というクラスもあります。

私の質問は-「ProductDTO」から「Product」にどこに翻訳すればよいですか？

サービスレイヤーに「Translate_ProductDTO_To_Product」関数が必要ですか？これは、「ProductDTO」が何であるかを知っている唯一のレイヤーであるため、最も論理的な答えのようです。

ただし、これは、サービス層が「製品」とは何かを認識している必要があるため、データアクセス層アセンブリを参照する必要があることを意味します。

これは正しいです ？

サービス層はビジネスロジック層のみを参照する必要があり、ビジネスロジック層はデータアクセス層のみを参照する必要があり、サービス層はDALについて何も知らないはずだと思いました。

4

2 に答える 2

2

Productデータレイヤーのクラスが実際にはProductエンティティであると想定すると、混乱が生じる可能性があります。一般に、ドメインドライバー設計では、ビジネスエンティティはビジネスロジックレイヤーに存在します。通常、これらのクラスは、データアクセス層の責任である永続性を「認識していません」（通常、オブジェクトリレーショナルマッパーフレームワークを使用します）。

実際には、サービスでは、有用な作業を実行するために、ドメインモデル（ビジネスレイヤー）とデータアクセスレイヤーの両方への参照が必要になります。WCFサービスコードとデータアクセス層の両方がドメインモデルに依存している必要がありますが、ドメインモデルはデータアクセス層またはWCFサービスコードのいずれにも依存してはなりません。

于 2012-04-23T12:55:08.320 に答える
1

DTOをサービスレイヤーのドメインエンティティにマップします。サービスレイヤーは、DTOとそれがマッピング先（およびマッピング元）のエンティティについて知る必要があります。手作りではなく、AutoMapperなどのツールを使用してマッピングを行うことを強くお勧めします 。サービス層はDA層（またはアセンブリ）を参照しないでください。BLは後で、エンティティを永続化するためにDAレイヤーを参照する必要があります。編集：あなたのビジネスの誘惑はおそらくDA名前空間の下にあるべきではありません。ORMツールを使用してそれらを生成している場合は、DDDロジックを部分クラスの残りの半分に配置していることを確認してください。

于 2012-04-23T13:07:16.093 に答える