JHipster VMsとDTOs

Question

JHipsterのDTO生成オプションの決定についてもう少し理解したいと思います。私はそれについていくつか質問があります。

1. なぜDTOと呼ばれますか？ release notes of JHipster 3.6.0には、これらのオブジェクトでビジネスロジックを実行するために使用できることが記述されています。これが実際にその意図であれば、それはDTO（データ転送オブジェクト）だけではありません。それは、私の意見では、ドメインオブジェクトです。ドメインオブジェクトはDTOやエンティティなどの親用語としても解釈されるため、これは理想的な用語ではないでしょう。DDDの観点からは、複数のドメインオブジェクトを組み合わせるため、Aggregateとも呼ばれます。

2. 現在のDTOの足場は、複数の実体を組み合わせたDTOの意図にうまく適合しないと私は考える。その場合、特定の1つのエンティティに関連するものではないため、そのエンティティのコンテキストで生成されるべきではありません。

3. 私は現在のDTOの足場は、JHipsterのVM（View Models）の定義にはるかに適していると思います。多くのリレーションを持つ複雑なエンティティや、おそらくBLOBやCLOBデータがある場合は、そのデータをすべてフロントエンドに送信したくない場合があります。依存オブジェクトを切り捨てるためには、UIが必要としないVMが必要です。これは、関係がIDによってのみ表されるので、現在のDTO足場にうまく適合します。これはまだJHipsterのウェブサイトDTOsに記載されています。私はこの説明は非難され、VMには適しているが、DTOにとってはうまくいかないと思う。ここでJHipsterのウェブサイトからの引用されています

これらのオブジェクトは、ドメインオブジェクトの上に余分なレイヤを追加し、具体的には、REST層

用にチューニングされているがのDTOの概念を持っていますVMは完全には考えられていないか、いくつかの重要な側面が欠落していますか？

Answer 1

私はなぜチームによって決定されたのかは言えませんが、私は、DTO/VMの概念があまり明確ではないことに絶対に同意します。

基本的な考えは、MVVMパターンを取得するためにしばしば新しいビューモデルが導入されるMVP/MVCパターンに似ていたと思います。したがって、ビューに影響を与えないDTOは、実際のモデル/コントローラレイヤに「プッシュ」されました。あなたがDTOがサービス間の転送オブジェクトであると言うなら、どちらがいいですか。

しかし、以前のjhipster-appでは、レイヤーやDTO、VMなどとの「トラブル」と多くの議論もありました。私たちはジフスターがDTOとMapstructを導入したのと同時にスタートしました。 Jhipsterを使用する新しいプロジェクトでは、常にすべてのDTOとVMを削除します。まず第一に、（Managed）UserVM/DTOのものですが、これは非常に混乱します。これにはいくつかの理由があります。

私たちのアプリケーションのサーバー側にはVMがありません。ビューが完全にjavascript/angularに基づいているjhipsterアプリケーションでは、ビューモデルがそこになければなりません。私たちはしばしばREST-APIを使用する他のアプリケーションを持っており、これらのアプリケーションはビューではありません。したがって、特にマイクロサービスアーキテクチャでは、REST-APIの「ビュー」や「ビューモデル」で何かを呼び出すことはありません。 したがって、Java（JSPなど）で表示されないビューでは、Javaコードでは「VM」という用語を見つけることはありません。さらに、さまざまな種類のビュー（角度ウェブアプリ、iOSアプリ、デスクトップクライアントなど）があり、それぞれに他のビュー、ビューパーツ、ウィジェットがあり、他のビューモデルが必要です。最後に、REST-APIが実際のリソース/エンティティではないものを提供しないかもしれないと言う人がいました...

したがって、jhipsterのVMは実際にはDTOであることは間違いありません。しかし、通常、DTOは、ロジックなしで2つ以上のサービス（またはシステム）間の共通の値をカプセル化するためのステートレスな転送オブジェクトであるため、「DTO」には問題があります。これは、JHipsterアプリで何らかの形で混在している、トップダウン（REST）APIドリブンとボトムアップドメインドリブンデザインの間のアーキテクチャ上の問題でもあると考えています。あなたの意見に似て、私はJHipsterがDTOをドメインオブジェクト（またはエンティティ）にするべきだと思っています。例えば。管理対象ユーザーはVMまたはDTOではないため、エンティティです。私は、ここでの問題は、JPAベースのエンティティだけがドメインオブジェクトであり、他のドメインオブジェクト（エンティティ）は存在しないと思う人がいるということです。

最後に、適合する用語が見つからないため、ADO（APIデータオブジェクトまたはアクセスデータオブジェクト）という新しいタイプを導入することにしました。 ADOは、VM、DTO、または論理なしのエンティティでさえ、jhipsterと比較されます。一般的な「APIレイヤー」はADOだけを読み書きします。このレイヤーは、REST APIコントローラー、およびプラグインで使用できるJava API用に使用されます。これにより、特定の内部エンティティまたはドメインオブジェクトを追加することなく、すべてのADOをクライアントAPIジャーで出荷することができます。 REST-APIと各プラグインは同じADO（したがって同じ記述と構造）を使用するため、開発者は混乱することはなく、外部リソース指向のレイヤーは、リソースベースのレイヤーだけでなく、ベース。

エンティティ、派生エンティティ、サブセット、またはエンティティのスーパーセットのような内部レイヤの一部であるすべてのものは、ほとんどがドメインオブジェクトです。そこで、この内部層、ビジネスロジックなどからすべてのVMとDTOを削除しました。

合計：内部アクセス（JPA）エンティティを外部アクセスからカプセル化するには、ビュー以外のものがある可能性があるため、ADOを使用します。これらのADOは、ジープスターVMとDTOの観点からのものです。しかし、一般的なAPIレイヤの背後には内部的にDTOやVM、さらにはADOも使用されません。これらのエンティティは主にドメインオブジェクトです。