この議論が繰り返し起こると思う理由の1つは、必要なすべてのデータを持つオブジェクトを取得し、それと同一またはほぼ同一に見えるオブジェクトに変換することは深刻な苦痛のようだからですあなたは引き渡し中です。
それは本当です、それはピタです。しかし、そうすることにはいくつかの理由があります（上記に列挙されたものに加えて）。
- ドメインオブジェクトは非常に重くなり、呼び出しに役に立たない情報が多く含まれることがあります。この膨張により、すべてのデータが送信、マーシャリング/アンマーシャリング、および解析されるため、UIの速度が低下します。FEにWebサービスを参照する多数のリンクがあり、AJAXまたは他のマルチスレッドアプローチで呼び出されることを考慮すると、UIがすぐに遅くなります。これはすべて、Webサービスの一般的なスケーラビリティに到達します。
- 大量のデータを公開すると、セキュリティが簡単に侵害されます。DTOの結果からそれらを削除しない場合、少なくともユーザーのメールアドレスと電話番号を公開できます。
- 実用上の考慮事項：1つのオブジェクトが永続ドメインオブジェクトとDTOとしてパレードするには、コードよりも多くのアノテーションが必要です。オブジェクトがレイヤーを通過する際のオブジェクトの状態の管理には、多くの問題があります。一般に、これは、管理するPITAに過ぎず、単にドメインオブジェクトからDTOにフィールドをコピーするという退屈な作業です。
ただし、変換ロジックをコンバータークラスのコレクションにカプセル化すると、かなり効果的に管理できます。
'convert（domainObj、toDto）'を実行できるlambdaJを見てください。コレクションで使用するためのオーバーロードがあります。これを使用するコントローラーメソッドの例を次に示します。ご覧のとおり、それほど悪くはありません。
@GET
@Path("/{id}/surveys")
public RestaurantSurveys getSurveys(@PathParam("id") Restaurant restaurant, @QueryParam("from") DateTime from, @QueryParam("to") DateTime to) {
checkDateRange(from, to);
MultiValueMap<Survey, SurveySchedule> surveysToSchedules = getSurveyScheduling(restaurant, from, to);
Collection<RestaurantSurveyDto> surveyDtos = convert(surveysToSchedules.entrySet(), SurveyToRestaurantSurveyDto.getInstance());
return new RestaurantSurveys(restaurant.getId(), from, to, surveyDtos);
}