web-dev-qa-db-ja.com

ドメインvsDTO vs ViewModel-それらをいつどのように使用するか？

ドメイン層（DL）/ビジネス（サービス）層（BL）/プレゼンテーション層（PL）を備えたマルチレイヤープロジェクトで、エンティティをプレゼンテーション層に配信するための最良のアプローチは何ですか？

DO => Domain Object;
DTO = Domain Transfer Object;
VM => View Model;
V => View;

オプション1：

DL => DO => BL => DTO => PL => VM => V

このオプションはベストプラクティスのようですが、維持するのも難しいようです。

オプション2：

DL => DO => BL => DTO => PL => V

このオプションはあまり良い方法ではないようですが、DTOはVMとほぼ同じであるため、ビューに直接渡すことができ、実装と管理の手間が軽減されます。

このオプションは、複数のレイアウトでも信頼できますか。たとえば、モバイルデバイスの場合、BLからの情報が少なくてすむため、この特定のレイアウトには異なるVMが必要になりますか？

asp.net-mvcentity-frameworkviewmodelautomapperdto
27
Patrick

DTOをビューに渡しても問題ありません。 DTOを変更または拡張する必要がある場合は、ViewModelを作成します。一般的なシナリオは、リンクを追加することです。 ViewModelがDTOを複雑なプロパティとして参照することも問題ありません。

10
Max Toro

Dtoとは異なるデータを必要とするさまざまなビューを使用する場合は、これらにさまざまなビューモデルを用意し、Dtoをこれらにマップすることでメリットが得られるようです。

この背後にある考え方の1つは、ビューモデルを自由に変更できるようにすることです。これにより、アプリケーションの他の部分に影響が及ばないことがわかります。 Dtoが複数のビューで使用されている場合、Dtoを変更するたびに、各ビューをテストする必要があります。

1
dove

私にとって、この決定は、検証ロジックをどこに置いたかに基づいています。

シナリオ＃1：ビューモデル（UIレイヤー）にデータ注釈を追加すると、プログラミングが大幅に簡素化されます。ほとんどの場合、DTOとビューモデルの間には1対1のマッピングがあります。このような場合、オプション1が適切です。 DL => DO => BL => DTO => PL => VM => V

シナリオ＃2）検証がViewModelsにアタッチされていない場合、DTOはViewModelに置き換えられ、ViewModelはビジネスレイヤーに存在します。 DL => DO => BL => VM => PL => V

シナリオ＃2は、検証ロジックがドメインモデルに存在する状況で最適です。そして、これらのモデルは多くのUIアプリケーションで使用されています。 UIは、ビジネスレイヤーによって指定されたように、エラーをリストにリストするだけです（ただし、あまりユーザーフレンドリーではありません）。アプリケーションがビジネスルールの変更を受けると、ドメインモデルのみが変更されます。この場合も、データベース関連の検証はEFを介して自動生成でき（.netを使用している場合）、変更の範囲はさらに狭くなります。

0
Blue Clouds

ここに私の返信を参照してください： https://stackoverflow.com/a/14059156/128806

あなたが言う：このオプションはベストプラクティスのようですが、維持するのも重いようです。

おそらく実装するのは重いですが、ほとんどの場合複製するコードはほんの数行ですが、確実に維持することはできません。

0
riadh gomri