wcf - WCFメッセージとデータの契約、DTO、ドメインモデル、および共有アセンブリ

Question

WCFビジネスサービスレイヤーを呼び出すWebクライアントがあり、WCFビジネスサービスレイヤーは外部のWCFサービスを呼び出して実際のデータを取得します。当初、私はDTOを使用し、異なるレイヤーに別々のビジネスエンティティを配置することを考えていました...しかし、DTOを提唱する些細な例は、まあ、些細なことであることがわかりました。重複したコードが多すぎて、メリットがあまりありません。

私のドメインを考えてみましょう：

ドメインの例私は単一のUI画面（Asp.net MVCビュー）を持っており、患者の投薬リスト、副作用（投薬間）、および患者が持つ可能性のある臨床状態（うつ病や高血圧など）を表示します。私のドメインモデルはトップレベルから始まります：

   MedicationRecord
      List<MedicationProfile> MedicationProfiles
      List<AdverseReactions> Reactions
      List<ClinicalConditions> ClinicalConditions

   MedicationProfile is itself a complex object
      string Name
      decimal Dosage
      Practitioner prescriber 

   Practioner is itself a complex object
      string FirstName
      string LastName
      PractionerType PractionerType
      PractionerId Id
      Address Address    

      etc.

さらに、WCF要求を行う場合、要求/応答オブジェクトがあります。

   MedicationRecordResponse
      MedicationRecord MedicationRecord
      List<ClientMessage> Messages
      QueryStatus Status

   and again, these other objects are complex objects
   (and further, complicates matter is that they exist in a different, common shared namespace)

この時点で、私の傾向は、MedicationRecordResponseが私のDTOであるということです。しかし、純粋なDataContractsとDTO、および設計の分離では、これを行うと思いますか？

   MedicationRecordResponseDto
      MedicationRecordDto
      List<ClientMessageDto> 
      QueryStatusDto

   and that would mean I then need to do
      MedicationProfileDto
      PractitionerDto
      PractitionerTypeDto
      AddressDto
   etc.

画面にほとんどすべての情報を表示しているので、所有しているドメインオブジェクトごとに1つのDTOを効果的に作成しています。

私の質問は-あなたはどうしますか？先に進んで、これらすべてのDTOを作成しますか？または、ドメインモデルを別のアセンブリで共有しますか？

関連性があると思われる他の質問からのいくつかの読み物は次のとおりです。

score 6 · Accepted Answer

優れた記事をご覧ください

上記のリンクは機能しません。ドメインの問題のようです (修正されることを願っています)。ソースは次のとおりです。

score 3 · Accepted Answer

個人的には、MessageContract をエンティティとして使用するのは好きではありません。残念ながら、MessageContract をエンティティとして使用する既存の WCF サービスがあります。つまり、データはデータアクセスレイヤーで直接 MessageContract に入力されます。関連する翻訳レイヤーはありません。

このサービスを使用する既存の C# コンソールアプリケーションクライアントがあります。さて、新たな要求があります。エンティティに新しいフィールドを追加する必要があります。これはクライアントには必要ありません。新しいフィールドは、サービスの内部計算専用です。エンティティとしても機能する「LDAPUserID」という名前の新しいプロパティを MessageContract に追加する必要がありました。

クライアントがLax Versioning. サービスのバージョン管理を参照してください。

新しいメンバーを追加しても既存のクライアントが壊れることはないと誤解しがちです。すべてのクライアントが緩いバージョン管理を処理できるかどうかわからない場合は、厳密なバージョン管理ガイドラインを使用し、データコントラクトを不変として扱うことをお勧めします。

この経験から、MessageContract をエンティティとして使用するのは良くないと思います。

また、MSDN - Service Layer Guidelinesも参照してください。

ビジネスエンティティとデータコントラクトの間を変換する変換オブジェクトを設計します。

参考文献:

score 3 · Accepted Answer

私は、DTO によってクラス階層が重複することを常に嫌っていました。これは、 DRY原則に対する重大な違反のようです。ただし、詳しく調べると、DTO と対応するエンティティ (複数可) は異なる役割を果たします。実際にドメイン駆動設計を適用している場合、ドメインエンティティはデータだけでなく動作で構成されます。対照的に、DTO はデータを運ぶだけで、ドメインと WCF の間のアダプターとして機能します。これらすべては、ポートおよびアダプターとも呼ばれる六角形のアーキテクチャー、およびオニオンアーキテクチャーのコンテキストではさらに理にかなっています。. ドメインはコアであり、WCF はドメインを外部に公開するポートです。DTO は WCF の機能の一部であり、それが必要悪であることに同意する場合、問題はそれらを排除しようとすることからそれらを受け入れることへと移行し、代わりに DTO とドメインオブジェクト間のマッピングを容易にする方法に焦点を合わせます。一般的なソリューションはAutoMapper ですこれにより、記述する必要があるボイラープレートマッピングコードの量が削減されます。欠点以外にも、DTO には多くの利点があります。1 つは、ドメインエンティティと外界との間にバッファーを提供することです。これは、コアドメインを適切にカプセル化した状態に保つことができるため、リファクタリングに非常に役立ちます。もう 1 つの利点は、サービスコンシューマの要件を満たすように DTO を設計できることです。この要件は、ドメインオブジェクトの形状と必ずしも完全に一致するとは限りません。

wcf - WCFメッセージとデータの契約、DTO、ドメインモデル、および共有アセンブリ

3 に答える 3

Related

Reference