バックエンドサービスでJSONオブジェクトまたはPOJOを使用しますか？
モバイルクライアント向けのバックエンドサービスを構築しています。
要件は、モバイルクライアントがトークンを渡すことです。そのトークンを使用して、会社内の（会社のファイアウォールの背後にある）他のシステムと通信し、ユーザーにいくつかの情報を返します。
典型的なシナリオは次のとおりです。
モバイルクライアントが顧客データを要求し、顧客トークンを使用して電話をかけます。顧客データベースシステムに対してトークンを使用して、顧客の詳細を取得します。次に、データを（関連しないいくつかのフィールドを削除して）モバイルクライアントに返します。
システム間のすべてのデータ（私、モバイルクライアント、顧客データベース）はJSonを使用します。
問題は、コード全体でJSonオブジェクトを操作する必要があるか、それともPOJOを使用するかどうかです。
現在、クライアントに戻る前に、顧客データベースからいくつかのフィールドを削除するだけで済みます。
将来はもっと複雑な変換が必要になるかもしれませんが、それが起こるか、変換の性質が確かではありません。
ありがとう
通常、シリアル化メソッド（JSON）をビジネスロジックから分離することをお勧めします。将来的に他のタイプのシリアル化を使用する場合、ビジネスロジックに影響を与えずに実行できるようになります。
Jackson は、おそらくJavaでのJSONシリアライゼーション/デシリアライゼーションの最も一般的なオープンソースライブラリです。
顧客データベースから受け取ったデータと実際に呼び出し元に返すものとの間である程度の変換が必要な状況では、通常、シリアル化するフィールドのみを含む個別のDTO（データ転送オブジェクト）クラスを作成します。
一方、送信する前に常に同じフィールドを顧客データから削除する必要があり、POJOにシリアル化固有の注釈を付けても構わない場合は、それらのフィールドでJacksonの@JsonIgnore（または同様の）を使用してスキップすることができます。 DTO。
私はあなたの現在の要件をカバーする最も簡単で最も簡単な解決策を探します。
必要なのはいくつかのフィールドを削除することだけですが、 json操作 で十分で、非常に簡単です。
将来、より複雑な変換（これはjson操作では簡単ではありません）に関しては、簡単にDTOを途中に追加して変換を行うことができると信じています。 jsonを取得してjsonを送り返すので、DTOを追加しても外部システムには影響しません。
その古典的なトレードオフパフォーマンス+使いやすさ対スケーラビリティと柔軟性。
POJOは非常にパフォーマンスが高く、Javaプログラムで簡単に使用できます。ただし、それらは単一のVMに制限されています。POJOを別のVMまたは別のサーバーまたはJavaで実装されていない別のプロセス。POJOをJavaプログラムを別のVMでプログラムに渡すには、POJOをシリアライズしてデシリアライズする必要があります。デフォルトでは、デフォルトのJava serializeメソッドは、使用されているJavaのバージョンに大きく依存していました。
JSON形式のメッセージは、プロセス間、サーバー間で受け渡すことができ、Javaプログラムだけでなく、JavaScript、php、python C、C++などでも使用できます。等.
JSON（またはXML :-)を使用する他の利点には、デバッグの容易さ（メッセージを読み取ることができる）とテストの容易さ（テストフレームワークで使用するためにJSONメッセージを保存およびコピーすることは簡単です）があります。
私は、最も単純なアプローチが一般的に最良であることに同意しています。私にとっては、JSON操作はこの状況で勝つことができます。
質問の重要な部分は「（モバイルクライアントに関連しないいくつかのフィールドを削除する）」です
したがって、私が理解していることから、複数のモバイルクライアントバリアントがあり、それぞれの異なるjsonフィールドに対して、ソース顧客データjsonから選択されます。
DTOアプローチを使用する場合、最初にソースの顧客データJSONをDTOにマーシャリングする必要があります。次に、4つのモバイルクライアントがある場合、4つのDTOと、DTOの各タイプの属性を設定するための複数の方法が必要になります。
JSONObjectアプローチを使用すると、次のようになります。
JSONObject sourceCustomerData = JSONObject.fromObject(httpResponseInputStream)
sourceCustomerDataをメソッドに渡して、個々のモバイルクライアントに適したJSONを次のように返します。
JSONObject customerDataClientX = getRequiredJson(requiredJsonFeildsForMobileClientA, sourceCustomerData)
ここで、requiredJsonFeildsForMobileClientAは必須JSONフィールドのリストです。したがって、モバイルクライアントごとに、必要なJSONフィールドの異なるリストを渡すことができます。
DTO PROS-単純明快で冗長なコードPOJO。 -より複雑な変換に適しています。 -簡単にテストできます。
DTOの短所-DTOはコードで保持されるモデルであり、コードを操作しないと変更できません。 -DTOなどのより多くのコードとそこにあるポピュレーションコードは、モバイルクライアントバリアントの数に直接関連しています。
JSONObject PROS
-単純なコード。 -簡単にテスト可能で、外部要因の関数です。 -1つの靴ですべてに対応できるため、コードが少なくて済み、モバイルクライアントのバリアントの数に直接関係しません
-コードに保持されるモデルはありません。各モバイルクライアントのJSONフィールドのリストは、外部の構成に保持できます。
JSONObject CONS
-より複雑な変換には適していません。 -JSONObjectはナビゲーションJSONモデルを必要とするため、準備や書き込みはそれほど必要ありません。
将来的には、より複雑な変換が必要になるため、追加することができます。さらに、タスクを容易にする場合は、DTOのベースモデルへの移行を検討することもできます。