なぜJHipsterでDTOがサービスレイヤで生成され、RESTレイヤで生成されないのですか？

Question

私たちはJHipsterプロジェクトを開始し、DTOを使用しました。当初、私はファンではありませんでしたが、これによってRESTレイヤのDTOを実際にカスタマイズすることができました。完璧です。

今はJMSをプロジェクトに追加しており、メッセージリスナーがサービスレイヤにアクセスする必要があることを認識していますが、メッセージングレイヤではなくRESTレイヤに適したDTOが返されます。

JHipsterがサービス層でDTOを生成するのはなぜですか？なぜRESTレイヤーにはないのですか？このようにして、RESTとJMSの両方のレイヤー（とそれ以外のもの）は、エンティティのみを処理するサービスレイヤーにアクセスできます。次に、RESTとJMSの両方に、自分のニーズに適した独自のDTOがあります。

これが最初に行われた理由は何ですか？ おかげJHipsterで

Answer 1

は、あなたが実際にのDTOとVMいる：

• のDTO（データ転送オブジェクト）は、サービス層である：彼らは、トランザクション層からデータを取得するためにここにいます。アイデアは、サービスレイヤー内には、関係がある（Hibernateで遅延ロードされた）JPAエンティティがあり、サービスレイヤーはHibernateによって管理されていないDTOを返すことです（レイジーロードはこれ以上ありません）。エンティティとDTOの間には1対1の関係はないかもしれません。おそらく、DTOは複数のエンティティを集約します。多分、それらはすべてあなたのビジネスモデルに依存するより多くのフィールド（またはより少ないフィールド！
• VM（ビューモデル）はビューレイヤーにあります。この言葉はAngularのもので、ここには多くの場合「vm」オブジェクトがあります。このアイデアは、ビューレイヤーに固有のオブジェクトを持つことで、クライアントアプリケーションをコーディングするのが簡単で、セキュリティが強化され、パフォーマンスが向上します。 DTOのデータは複数の異なる画面で使用される可能性があるため、1つのDTOに対して複数のVMが存在する可能性があります。通常、VMはJSONでJavaのバックエンドからJavaScriptのフロントエンドに転送されるものです。

これらのレイヤーはいずれもJHipsterでは必須ではありません。あなたは一般的にあります：シンプルCRUDsため

• ただ、実体ビジネスコード用
• エンティティとのDTO
• エンティティと仮想マシンの特定、複雑なビューがある
• エンティティ、DTOSとVMすべてがあります複合体