web-dev-qa-db-ja.com

各レイヤーのデータオブジェクト(DTO vsエンティティvs応答オブジェクト)

残りのエンドポイントも公開する(Spring Boot 2で)Customer Webアプリケーションを構築しているとしましょう。アプリケーションを3つのレイヤーにモデル化しています。

  1. a)UI-CustomerDTO

    b)REST-CustomerRESTResponse/CustomerRESTRequest

  2. サービス-CustomerDTO

  3. データ-Customer(エンティティ)

すべてのレイヤーに独自のビジネスオブジェクト表現が必要ですか?エンティティがDTOとほぼ同じである場合、その用途は何ですか?

6
Neo

ここには「正しい」答えはありません。それは本当にあなたが満足しているトレードオフを見つけることです。

レイヤー間で1つのモデルを共有すると、カップリングと引き換えに開発速度が向上します。コードをより高速に動作させることができますが、本質的にすべてのレイヤーを結合します。サービス層のモデルへの変更は、APIコンシューマーが見るモデルに影響します。

一方、各レイヤーに専用のモデルを用意すると、開発時間は長くなりますが、レイヤーが分離されます。サービスレイヤーのモデルに変更を加えても、他のレイヤーに自動的に細流されません。これにより、他のレイヤーのデータを誤って壊したり、不必要にAPIのコンシューマーやデータベースに不必要な情報を漏らしたりするリスクが軽減されます。

ここでの欠点は、前述のように、追加の先行開発費用と、モデルが実際に変更されるときに必要な追加費用doが適用される必要があることです。他のレイヤー。

つまり、疎結合と開発のスピードの間でトレードしているのです。

すべてのレイヤーに独自のビジネスオブジェクト表現が必要ですか?

いいえ、必要ありません必要はありません

保守コストよりも開発速度を重視する場合は、レイヤー間でモデルを共有することをお勧めします。

一方、ほとんどのソフトウェアプロジェクトのコストはメンテナンス段階にあります。したがって、メンテナンスを容易にするためにコードを整理すると、長期的には時間とお金を節約できます。

Shouldすべてのレイヤーに独自のビジネスオブジェクト表現がありますか?

答えは、最適化の目的によって異なります。

7
MetaFight