似たような質問をいくつか見ました:
また、それらが使用される文脈や目的についても教えていただけますか?
ベストアンサー1
JavaBeans
JavaBeanは、JavaBeansの規約サンの定義によると、Wikipediaには、JavaBeansは：
JavaBeans は、ビルダー ツールで視覚的に操作できる、Java の再利用可能なソフトウェア コンポーネントです。実際には、JavaBeans は特定の規則に従って Java プログラミング言語で記述されたクラスです。JavaBeans は、多数のオブジェクトを 1 つのオブジェクト (Bean) にカプセル化するために使用され、複数の個別のオブジェクトとしてではなく、単一の Bean オブジェクトとして渡すことができます。JavaBeans は、シリアル化可能で、nullary コンストラクターを持ち、getter メソッドと setter メソッドを使用してプロパティにアクセスできる Java オブジェクトです。
JavaBean クラスとして機能するには、オブジェクト クラスはメソッドの命名、構築、および動作に関する特定の規則に従う必要があります。これらの規則により、JavaBean を使用、再利用、置換、および接続できるツールが可能になります。
必要な規則は次のとおりです。
- クラスにはパブリック デフォルト コンストラクターが必要です。これにより、編集およびアクティベーション フレームワーク内で簡単にインスタンス化できます。
- クラスのプロパティは、標準の命名規則に従って、get、set、およびその他のメソッド (いわゆるアクセサー メソッドおよびミューテーター メソッド) を使用してアクセスできる必要があります。これにより、フレームワーク内で Bean の状態を簡単に自動的に検査および更新できます。多くのフレームワークには、さまざまな種類のプロパティ用のカスタム エディターが含まれています。
- クラスはシリアル化可能である必要があります。これにより、アプリケーションとフレームワークは、VM とプラットフォームに依存しない方法で Bean の状態を確実に保存、格納、および復元できます。
これらの要件は主にインターフェースを実装するのではなく規則として表現されるため、一部の開発者は JavaBeans を特定の命名規則に従う単純な古い Java オブジェクトと見なしています。
ポジョ
POJO（Plain Old Java Object）は、当初は、javax.ejb重いEJB 2.x（特にエンティティBean、ステートレスセッションBeanはそれほど悪くないと思う）とは対照的に、インターフェイスを実装しない単純な軽量Javaオブジェクトを指すために導入された用語です。今日では、この用語は余分なもののない単純なオブジェクトすべてに使用されています。ここでも、Wikipediaは定義をうまく行っています。ポジョ:
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 (Plain Old Data Structures)、Perl における POD (Plain Old Documentation) など、新しい高度な機能を使用しない技術を表す古い用語のパターンを引き継いでいます。
この用語が広く受け入れられた理由は、複雑なオブジェクト フレームワークとは対照的に、共通で理解しやすい用語が必要だったためと考えられます。JavaBean は、シリアル化可能で、引数なしのコンストラクタを持ち、getter メソッドと setter メソッドを使用してプロパティにアクセスできる POJO です。Enterprise JavaBean は単一のクラスではなく、コンポーネント モデル全体です (繰り返しますが、EJB 3 は Enterprise JavaBeans の複雑さを軽減します)。
POJO を使用した設計がより一般的に使用されるようになると、フレームワークで使用される機能の一部を POJO に提供し、実際に必要な機能領域についてより多くの選択肢を提供するシステムが登場しました。Hibernate や Spring がその一例です。
値オブジェクト
値オブジェクトまたはVOは、値を保持するオブジェクトですjava.lang.Integer（したがって、値オブジェクトと呼ばれます）。より正式な定義については、Martin Fowlerの次の説明をよく参照します。値オブジェクト:
エンタープライズ アプリケーション アーキテクチャのパターンでは、値オブジェクトを、Money オブジェクトや日付範囲オブジェクトなどの小さなオブジェクトとして説明しました。それらの重要な特性は、参照セマンティクスではなく値セマンティクスに従うことです。
通常、これらを判別できるのは、等価性の概念が同一性に基づいていないためです。代わりに、2 つの値オブジェクトは、すべてのフィールドが等しい場合に等価となります。すべてのフィールドが等しい場合でも、サブセットが一意である場合は、すべてのフィールドを比較する必要はありません。たとえば、通貨オブジェクトの通貨コードだけで、等価性をテストできます。
一般的なヒューリスティックは、値オブジェクトは完全に不変であるべきだということです。値オブジェクトを変更する場合は、オブジェクトを新しいオブジェクトに置き換え、値オブジェクト自体の値を更新できないようにする必要があります。更新可能な値オブジェクトはエイリアシングの問題を引き起こします。
初期のJ2EE文献では、値オブジェクトという用語を別の概念を表すために使用していました。これを私はデータ転送オブジェクトそれ以来、彼らはその用法を変え、オブジェクトの転送その代わり。
データ転送オブジェクト
データ転送オブジェクト（DTO）は、EJBで導入された（反）パターンです。EJBで多くのリモート呼び出しを実行する代わりに、ネットワーク経由で転送できる値オブジェクトにデータをカプセル化するというアイデアでした。それがデータ転送オブジェクトです。Wikipediaには、データ転送オブジェクト:
データ転送オブジェクト (DTO) は、以前は値オブジェクトまたは VO と呼ばれていましたが、ソフトウェア アプリケーション サブシステム間でデータを転送するために使用される設計パターンです。DTO は、データベースからデータを取得するために、データ アクセス オブジェクトと組み合わせて使用されることがよくあります。
データ転送オブジェクトとビジネス オブジェクトまたはデータ アクセス オブジェクトの違いは、DTO には独自のデータ (アクセサーとミューテーター) の保存と取得以外の動作がないことです。
従来の EJB アーキテクチャでは、DTO は 2 つの目的を果たします。1 つ目は、エンティティ Bean がシリアル化できないという問題を回避し、2 つ目は、プレゼンテーション層に制御を返す前に、ビューで使用されるすべてのデータがフェッチされ、DTO にマーシャリングされるアセンブリ フェーズを暗黙的に定義することです。
したがって、多くの人にとって、DTO と VO は同じものです (ただし、Fowler は、前述のように VO を別の意味で使用しています)。ほとんどの場合、それらは JavaBeans 規則に従っているため、JavaBeans でもあります。そして、すべてが POJO です。