同様の質問を見たことがあります:
また、それらが使用されるコンテキストを教えてください。それとも彼らの目的?
同様の質問を見たことがあります:
また、それらが使用されるコンテキストを教えてください。それとも彼らの目的?
JavaBean は、 Sun によって定義された JavaBeans 規則に従うクラスです。ウィキペディアには、 JavaBeansとは何かについてのかなり良い要約があります。
JavaBeans は、ビルダー ツールで視覚的に操作できる Java の再利用可能なソフトウェア コンポーネントです。実際には、特定の規則に準拠した Java プログラミング言語で記述されたクラスです。これらは、多くのオブジェクトを単一のオブジェクト (Bean) にカプセル化するために使用されるため、複数の個別のオブジェクトではなく、単一の Bean オブジェクトとして渡すことができます。JavaBean はシリアライズ可能で、nullary コンストラクターを持ち、getter メソッドと setter メソッドを使用してプロパティにアクセスできる Java オブジェクトです。
JavaBean クラスとして機能するために、オブジェクト クラスは、メソッドの命名、構造、および動作に関する特定の規則に従う必要があります。これらの規則により、JavaBeans を使用、再利用、置換、および接続できるツールを持つことが可能になります。
必要な規則は次のとおりです。
- クラスには、パブリックの既定のコンストラクターが必要です。これにより、編集およびアクティベーション フレームワーク内でのインスタンス化が容易になります。
- クラス プロパティは、標準の命名規則に従って、get、set、およびその他のメソッド (いわゆるアクセサ メソッドおよびミューテータ メソッド) を使用してアクセスできる必要があります。これにより、フレームワーク内で Bean の状態を簡単に自動検査および更新できます。その多くには、さまざまなタイプのプロパティのカスタム エディターが含まれています。
- クラスはシリアライズ可能である必要があります。これにより、アプリケーションとフレームワークは、VM とプラットフォームに依存しない方法で、Bean の状態を確実に保存、保存、および復元できます。
これらの要件は、インターフェースの実装ではなく、規約として大部分が表現されるため、一部の開発者は、JavaBeans を特定の命名規約に従う Plain Old Java Objects と見なします。
javax.ejb
Plain Old Java Object または POJO は、重量級の EJB 2.x (特にエンティティ Bean、ステートレス セッション Beans はそれほど悪い IMO ではありません) とは対照的に、インターフェースを実装しない単純な軽量 Java オブジェクトを示すために最初に導入された用語です。今日、この用語は余分なもののない単純なオブジェクトに使用されています。繰り返しになりますが、ウィキペディアはPOJOの定義に優れています。
POJO は Plain Old Java Object の頭字語です。この名前は、問題のオブジェクトが特別なオブジェクトではなく通常の Java オブジェクトであり、特にエンタープライズ JavaBean (特に EJB 3 より前) ではないことを強調するために使用されます。この用語は、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 はシリアライズ可能な POJO であり、引数のないコンストラクターを持ち、getter メソッドと setter メソッドを使用してプロパティにアクセスできます。エンタープライズ JavaBean は単一のクラスではなく、コンポーネント モデル全体です (ここでも、EJB 3 はエンタープライズ JavaBean の複雑さを軽減しています)。
POJO を使用した設計がより一般的に使用されるようになるにつれて、フレームワークで使用される機能の一部を POJO に提供し、どの機能領域が実際に必要とされるかについてより多くの選択肢を提供するシステムが登場しました。Hibernate と Spring がその例です。
値オブジェクトまたは VO は、java.lang.Integer
値を保持するようなオブジェクトです (したがって、値オブジェクト)。より正式な定義については、Martin Fowler のValue Objectの説明をよく参照します。
エンタープライズ アプリケーション アーキテクチャのパターンでは、Value Object を Money や日付範囲オブジェクトなどの小さなオブジェクトとして説明しました。それらの重要な特性は、参照セマンティクスではなく値セマンティクスに従うことです。
等しいという概念は ID に基づいていないため、通常はそれらを伝えることができます。代わりに、すべてのフィールドが等しい場合、2 つの値オブジェクトは等しいと見なされます。すべてのフィールドは等しいですが、サブセットが一意である場合は、すべてのフィールドを比較する必要はありません。たとえば、通貨オブジェクトの通貨コードは、等しいかどうかをテストするのに十分です。
一般的なヒューリスティックは、値オブジェクトは完全に不変であるべきだということです。値オブジェクトを変更したい場合は、そのオブジェクトを新しいものに置き換え、値オブジェクト自体の値を更新できないようにする必要があります。更新可能な値オブジェクトはエイリアシングの問題を引き起こします。
初期の J2EE 文献では、値オブジェクトという用語を使用して、私がData Transfer Objectと呼んでいる別の概念を説明していました。その後、使用方法が変更され、代わりに転送オブジェクトという用語が使用されています。
wiki やDirk Riehleで、値オブジェクトに関するさらに優れた資料を見つけることができます。
データ転送オブジェクトまたは DTO は、EJB で導入された (アンチ) パターンです。EJB で多くのリモート呼び出しを実行する代わりに、ネットワーク経由で転送できる値オブジェクト (データ転送オブジェクト) にデータをカプセル化するというアイデアがありました。ウィキペディアには、Data Transfer Objectの適切な定義があります。
以前は値オブジェクトまたは VO と呼ばれていたデータ転送オブジェクト (DTO) は、ソフトウェア アプリケーション サブシステム間でデータを転送するために使用される設計パターンです。DTO は、多くの場合、データベースからデータを取得するためにデータ アクセス オブジェクトと組み合わせて使用されます。
データ転送オブジェクトとビジネス オブジェクトまたはデータ アクセス オブジェクトの違いは、DTO には自身のデータ (アクセサーとミューテーター) の格納と取得以外の動作がないことです。
従来の EJB アーキテクチャでは、DTO は 2 つの目的を果たします。まず、エンティティ Bean がシリアル化できないという問題を回避します。次に、ビューで使用されるすべてのデータがフェッチされ、DTO にマーシャリングされてから、制御がプレゼンテーション層に返されるアセンブリ フェーズを暗黙的に定義します。
したがって、多くの人にとって、DTO と VO は同じものです (しかし、Fowler は VO を別の意味で使用しています)。ほとんどの場合、これらは JavaBeans 規則に従っているため、JavaBeans でもあります。そしてすべてが POJO です。
DTOとVO
DTO-データ転送オブジェクトは、レイヤーとティアの間でデータを転送するために使用される単なるデータコンテナーです。
例え:
ユーザー名、パスワード、電子メールIDの属性を持つ単純な登録フォーム。
- このフォームがRegistrationServletファイルで送信されると、ビューレイヤーからビジネスレイヤーにすべての属性を取得し、そこで属性をJava Beanに渡し、次にDAOまたは永続レイヤーに渡します。
- DTOは、属性をビューレイヤーからビジネスレイヤーに、そして最後に永続レイヤーに転送するのに役立ちます。
DTOは主に、ネットワークを介してデータを効率的に転送するために使用されました。JVMから別のJVMに転送される場合もあります。
多くの場合、DTOはjava.io.Serializable
、JVM間でデータを転送するためのものです。
VO-値オブジェクト[1][2]は、それ自体が固定されたデータセットを表し、Java列挙型に似ています。値オブジェクトのIDは、オブジェクトIDではなく状態に基づいており、不変です。実際の例は、Color.RED、Color.BLUE、SEX.FEMALEなどです。
POJOとJavaBeans
[1] POJOのJava-Beannessは、そのプライベート属性がすべて、JavaBeansの規則に準拠するパブリックゲッターおよびセッターを介してアクセスされることです。例えば
private String foo;
public String getFoo(){...}
public void setFoo(String foo){...};
[2] JavaBeansはSerializableを実装し、引数のないコンストラクターを持っている必要がありますが、POJOではこれらの制限はありません。
Java Bean は EJB と同じではありません。
Java 1.0のJavaBeans 仕様は、Java オブジェクトを VB のような IDE で操作できるようにする Sun の試みでした。「Java Beans」として認定されたオブジェクトに対して定められた規則がありました。
EJB は後で登場しました。これらは分散コンポーネントとトランザクション モデルを組み合わせ、スレッド、プーリング、ライフ サイクルを管理し、サービスを提供するコンテナーで実行されます。それらは Java Beans とはかけ離れています。
DTO が Java コンテキストで登場したのは、EJB 1.0 仕様がデータベースとあまりにも「おしゃべり」すぎることが判明したためです。すべてのデータ要素を往復するのではなく、それらをまとめて Java Bean にパッケージ化して出荷していました。
POJO は EJB に対する反応でした。
POJO : 他の Java ファイル (クラス) を拡張または実装しない Java ファイル (クラス) です。
Bean : すべての変数がプライベートで、メソッドがパブリックであり、変数にアクセスするために適切なゲッターとセッターが使用される Java ファイル (クラス) です。
通常クラス: public/private/default/protected 変数で構成され、別の Java ファイル (クラス) を拡張または実装する場合としない場合がある Java ファイル (クラス) です。