RESTfulなWebサービスでは、POJO/JSON変換用のDTOオブジェクトとデータベースエンティティ/ POJO用のDTOオブジェクト変換？Springブート、RESTとJPAの両方に別々にDTOオブジェクトを作成することの決定
Spring Bootは、より多くの意見を述べ、使いやすくする必要がありますが、JSONとデータベースエンティティの表現には異なるDTOオブジェクトタイプを使用しますか、エンティティオブジェクトをJSONに直接変換しますか？
私の意見を分かち合いましょう。
まず、あなたの質問は、春のブーツとは関係がないと思います。春のブートは、アプリケーションを起動するための派手で軽量な方法を提供するだけで、簡単な方法でアプリケーションを構築することができます。 しかし、あなたはまだそこにあなたの残りのコントローラを持って、それは他のアプリケーションの種類のために多くの違いはありませんその点から。
JSONオブジェクトの抽象概念を維持し、それらをBusiness Logic Entityオブジェクトに変換し、後でもう一度それらをデータベースオブジェクトに変換するか、2レベルだけを維持するのに十分なのかJsonレベルを捨てる。
私は答えが「それは依存している」と思います。
まず、一般に、現在の傾向は単純化されています。それで1つのレベルのオブジェクトだけを維持するのに十分かもしれません。
ようなアプローチの利点がたくさんあります：開発とテストの
しかし、このような単純化の欠点が1つあります。
一言で私は、アプリケーション内のAPIの3種類があり
コミットメントそれを呼び出します。
WebサービスのレベルでコミットしているAPI - JSon構造。 さまざまなクライアント（JVMを使用する必要はありません）がWebサービスに対して実行され、データを消費する可能性があります。したがって、彼らは実際にあなたが与えられた構造のJSonオブジェクトを提供することを期待しています。
あなたのビジネスのAPI。ビジネスロジックレイヤーがかなり複雑な場合は、チーム全体がそのロジックを開発している可能性があります。だからあなたは通常、チーム間のAPIのレベルで作業します。
DAOのレベル - 実際にはビジネスロジックと同じ話です。
これで、あるレベルでそのAPIを変更するとどうなりますか。すべてのレベルが壊れることを意味しますか？
例
私たちは "JSON" レベルを維持していない、と言うことができます。この場合、Business LogicのレベルでAPIを変更すると、JSONも自動的に変更されます。すべての残りのフレームワークは私たちのためにオブジェクトを喜んで変換し、ユーザーは別のデータを取得する可能性があります。
が言うことができます別の例として、あなたのBL層はこのようになりますPersonエンティティ提供：
class Person {
String firstName;
String lastName;
List<Language> languages;
}
class Language {
...
}
を今、あなたが提供してあなたのRESTサービスを消費UIを持っているとしましょう要求に応じて人のリスト。 UIに2つの異なるページがある場合はどうなりますか？人のみを表示するもの（この場合、人が話す言語のリストを提供することは意味がありません）。 しかし、2番目のページでは完全な情報を得たいと思っています。
これで、2つのWebサービスが公開されたり、既存のパラメータがいくつかのパラメータによって複雑になることになります（このようなパラメータが多いほど、残りの部分に似ていません:)） 分離はここで少し役立ちますか？知りません。
ボトムライン。 私は、あなたがそのような分離なしで生きていける限り、それをすると言います。非常に大きなプロジェクトでも機能します。もちろん、中小規模のプロジェクトでも機能します。
あなたが修正プログラムを苦労していると感じたら、このような分離が問題を解決すると思います。
これは意味を理解するのに役立ち、あなたのために何が効果的かを選択します。