DTO、VO、POJO、JavaBeansの違いは？
同様の質問をいくつか見たことがあります。
また、それらが使われている文脈を教えてください。それともそれらの目的は？
JavaBeans
JavaBeanは、Sunによって定義された JavaBeans規約 に従うクラスです。ウィキペディアには、 JavaBeans の概要がかなりまとめられています。
JavaBeansはビルダーツールで視覚的に操作できるJava用の再利用可能なソフトウェアコンポーネントです。実際には、それらは特定の規約に準拠したJavaプログラミング言語で書かれたクラスです。これらは、多数のオブジェクトを単一のオブジェクト（Bean）にカプセル化するために使用されるので、それらを複数の個別のオブジェクトとしてではなく、単一のBeanオブジェクトとして渡すことができます。 JavaBeanは直列化可能なJavaオブジェクトで、nullコンストラクタを持ち、getterメソッドとsetterメソッドを使用してプロパティにアクセスできます。
JavaBeanクラスとして機能するためには、オブジェクトクラスは、メソッドの命名、構成、および動作に関する特定の規約に従う必要があります。これらの規約により、JavaBeansを使用、再利用、置換、および接続できるツールを持つことが可能になります。
必要な規則は次のとおりです。
- クラスにはパブリックのデフォルトコンストラクタが必要です。これにより、編集およびアクティブ化フレームワーク内で簡単にインスタンス化できます。
- クラスのプロパティは、標準の命名規則に従って、get、set、およびその他のメソッド（いわゆるアクセサメソッドおよびミューテータメソッド）を使用してアクセスできる必要があります。これにより、フレームワーク内でBeanの状態を簡単に自動検査および更新することができます。フレームワークの多くには、さまざまなタイプのプロパティ用のカスタムエディタが含まれています。
- クラスは直列化可能であるべきです。これにより、アプリケーションやフレームワークは、VMおよびプラットフォームに依存しない方法で、Beanの状態を確実に保存、格納、および復元できます。
これらの要件は主にインタフェースの実装ではなく規約として表現されているため、一部の開発者はJavaBeansを特定の命名規約に従う普通のJavaオブジェクトと見なしています。
POJO
Plain Old Java Object（POJO）は、ヘビー級EJB 2.x（特にEntity Beans、Stateless Session Beansはそれほど悪いIMOではありません）とは対照的に、javax.ejbインターフェースを実装しない、単純な軽量Javaオブジェクトを指すために最初に導入された用語です。今日では、この用語は余分なものがない単純なオブジェクトに使用されています。繰り返しますが、ウィキペディアは POJO を定義するのに適しています。
POJOはPlain Old Java Objectの頭字語です。この名前は、問題のオブジェクトが特別なオブジェクトではなく、特にEnterprise JavaBeanではない（特にEJB 3より前の）通常のJavaオブジェクトであることを強調するために使用されています。この言葉は、2000年9月にMartin Fowler、Rebecca Parsons、Josh MacKenzieによって造られました。
"私たちはなぜ人々が自分たちのシステムで通常のオブジェクトを使うのをそんなに反対したのかと疑問に思い、単純なオブジェクトには派手な名前がなかったからだと結論づけました。
この用語は、テレフォニーでPOTS（Plain Old Telephone Service）やC++で定義されているがC言語の機能のみを使用するPODSなど、見慣れない新機能を使用しないテクノロジの古い用語のパターンを引き継いでいます。 PerlのPOD（Plain Old Documentation）。
この用語は、複雑なオブジェクトフレームワークと対比される一般的で理解しやすい用語が必要であるため、最も広く受け入れられている可能性があります。 JavaBeanはシリアライズ可能なPOJOであり、引数なしのコンストラクタを持ち、getterメソッドとsetterメソッドを使用してプロパティにアクセスできます。 Enterprise JavaBeanは単一クラスではなく、コンポーネントモデル全体です（ここでもEJB 3はEnterprise JavaBeansの複雑さを軽減します）。
POJOを使用した設計がより一般的に使用されるようになるにつれて、フレームワークで使用される機能の一部と実際に必要とされる機能の分野に関する選択の幅をPOJOに与えるシステムが生まれました。 HibernateとSpringはその一例です。
値オブジェクト
Value ObjectまたはVOは、値を保持するJava.lang.Integerなどのオブジェクトです（したがって値オブジェクト）。より正式な定義については、Martin Fowlerによる Value Object の説明をよく参照してください。
エンタープライズアプリケーションアーキテクチャのパターンで、ValueオブジェクトをMoneyや日付範囲オブジェクトなどの小さなオブジェクトとして説明しました。それらの重要な特性は、それらが参照セマンティクスよりむしろ値セマンティクスに従うということです。
それらの平等の概念はアイデンティティに基づいていないので、通常それらを言うことができます、その代わりにそれらのすべてのフィールドが等しいならば2つの値オブジェクトは等しいです。すべてのフィールドは同じですが、サブセットが一意の場合は、すべてのフィールドを比較する必要はありません。たとえば、通貨オブジェクトの通貨コードは同等性をテストするのに十分です。
一般的な発見的手法は、値オブジェクトは完全に不変でなければならないということです。値オブジェクトを変更したい場合は、オブジェクトを新しいものに置き換えて、値オブジェクト自体の値を更新することを許可しないでください。更新可能な値オブジェクトはエイリアシングの問題につながります。
初期のJ2EEの文献では、値オブジェクトという用語を使用して、私が データ転送オブジェクト と呼んでいる別の概念を説明していました。彼らはその後使用法を変更し、代わりに オブジェクト転送 という用語を使用しました。
あなたは wiki 上の、そして Dirk Riehle 上の値オブジェクトに関するもっと良い資料を見つけることができます。
データ転送オブジェクト
データ転送オブジェクト（DTO）はEJBで導入された（反）パターンです。 EJBで多くのリモート呼び出しを実行するのではなく、ネットワークを介して転送可能な値オブジェクト、つまりデータ転送オブジェクトにデータをカプセル化するという考えでした。ウィキペディアには データ転送オブジェクト の適切な定義があります。
以前は値オブジェクトまたはVOと呼ばれていたデータ転送オブジェクト（DTO）は、ソフトウェアアプリケーションサブシステム間でデータを転送するために使用されるデザインパターンです。 DTOは多くの場合、データベースからデータを取得するためにデータアクセスオブジェクトと組み合わせて使用されます。
データ転送オブジェクトとビジネスオブジェクトまたはデータアクセスオブジェクトとの違いは、DTOはそれ自身のデータ（アクセサーとミューテーター）の格納と検索を除いて、どんな振る舞いもしないということです。
従来のEJBアーキテクチャでは、DTOは2つの目的を果たします。まず、エンティティBeanが直列化できないという問題を回避します。次に、プレゼンテーション層に制御を返す前に、ビューで使用されるすべてのデータがフェッチされてDTOにマーシャリングされるアセンブリフェーズを暗黙的に定義します。
したがって、多くの人にとって、DTOとVOは同じものです（ただし、FowlerはVOを使って他の何かを意味します）。ほとんどの場合、これらはJavaBeansの規約に従っているため、JavaBeansでもあります。そしてすべてがPOJOです。
DTOとVO
DTO /データ転送オブジェクトは、レイヤとティアの間でデータを転送するために使用される単なるデータコンテナです。
- 主に属性が含まれています。ゲッターやセッターなしでpublic属性を使うことさえできます。
- データ転送オブジェクトには、ビジネスロジックは含まれていません。
アナロジー：
ユーザー名、パスワード、および電子メールIDという属性を持つ単純な登録フォーム。
- このフォームがRegistrationServletファイルに送信されると、ビュー層からビジネス層に至るすべての属性を取得し、そこでその属性をJava Beanに渡し、次にDAOまたは永続化層に渡します。
- DTOは、ビュー層からビジネス層、そして最後に永続層に属性を転送するのに役立ちます。
DTOは主にネットワーク上でデータを効率的に転送するために使用されていました。それはJVMから別のJVMへの転送でさえあります。
JVM間でデータを転送するために、DTOはしばしばJava.io.Serializableです。
VO - / Valueオブジェクト[1] [2]は、それ自体が固定されたデータセットを表し、Java enumに似ています。値オブジェクトのアイデンティティは、オブジェクトのアイデンティティではなく状態に基づいており、不変です。実世界の例は、Color.RED、Color.BLUE、SEX.FEMALEなどです。
POJOとJavaBeans
[1] POJOのJava-Beannessは、そのプライベート属性がすべてJavaBeans規約に準拠したパブリックのgetterおよびsetterを介してアクセスされることです。例えば.
private String foo;
public String getFoo(){...}
public void setFoo(String foo){...};
[2] JavaBeansはSerializableを実装しなければならず、引数なしのコンストラクタを持たなければなりませんが、POJOではこれらの制限はありません。
基本的に、
DTO： "データ転送オブジェクト"はソフトウェアアーキテクチャの別々の層の間を行き来することができます。
VO： "Value objects"はIntegerやMoneyなどのオブジェクトを保持します.
POJO：特別なオブジェクトではない普通の古いJavaオブジェクト。
Java Beans：シリアライズ可能であること、各フィールド用のJava Classコンストラクターおよびゲッターおよびセッターを持つことがno-argを必要とします
Java BeansはEJBと同じものではありません。
Java 1.0の JavaBeans仕様 は、VBのように見えるIDE内でJavaオブジェクトを操作できるようにするためのSunの試みでした。 「Java Beans」として認定されたオブジェクトには、次のような規則があります。
- デフォルトコンストラクタ
- 適切な命名規則に従ったプライベートデータメンバーのゲッターとセッター
- 直列化可能
- 私が忘れているのかもしれません。
EJBは後で登場しました。それらは、分散コンポーネントとトランザクションモデルを組み合わせ、スレッド、プール、ライフサイクルを管理し、サービスを提供するコンテナ内で実行します。それらはJava Beansからはかけ離れています。
EJB 1.0仕様がデータベースに対してあまり「おしゃべり」であることを人々が知ったため、DTOはJavaのコンテキストで生まれました。データ要素ごとに往復するのではなく、人々はそれらをまとめてJavaBeansにまとめて出荷します。
POJOはEJBに対する反応でした。
_ pojo _ ：他のJavaファイル（クラス）を拡張または実装していないJavaファイル（クラス）です。
Bean ：すべての変数がプライベートで、メソッドがパブリックで、変数へのアクセスに適切なゲッターとセッターが使用されているJavaファイル（クラス）です。
通常のクラス ：これは、public/private/default/protected変数で構成されている可能性があり、他のJavaファイル（クラス）を拡張または実装していない可能性があるJavaファイル（クラス）です。
ファーストトークについて
標準クラス - これは、通常Javaで定義されているすべてのクラス定義を意味します。つまり、さまざまなタイプのメソッドプロパティを作成するということです -
Bean - / Beanは、このBeanを使用してその特定のクラスのオブジェクトにすぎないもので、object.と同じようにJavaクラスにアクセスできます。
そしてその後の最後の1 POJOについての話
_ pojo _ - _ pojo _ は、デフォルトコンストラクタとプライベートプロパティ、および値に対応する設定メソッドと取得メソッドを設定するためのプロパティのみを持つサービスです。プレーンJavaオブジェクトの短縮形です。
- 値オブジェクト ：オブジェクトの値に基づいてオブジェクトの同等性を測定する必要がある場合に使用します。
- データ転送オブジェクト ：リモートサーバーへの複数の呼び出しを回避するために、複数の属性を持つデータをクライアントからサーバーにレイヤー間でワンショットで渡します。
- 普通の古いJavaオブジェクト ：これは単純なクラスのプロパティで、パブリック引数なしのコンストラクタです。 JPAエンティティとして宣言しています。