違いについてはわかりません。私はHibernateを使用していますが、一部の書籍では、JavaBeanとPOJOを交換可能な用語として使用しています。 Hibernateコンテキストだけでなく、一般的な概念にも違いがあるかどうかを知りたいです。
JavaBeanは特定の規則に従います。ゲッター/セッターの命名、パブリックデフォルトコンストラクターの使用、シリアル化など。詳細については、 JavaBeans Conventions を参照してください。
POJO(plain-old-Java-object)は厳密に定義されていません。特定のインターフェースを実装したり、特定の基本クラスから派生したり、特定のフレームワークと互換性を保つために特定の注釈を使用したりする必要がないJavaオブジェクトです。任意の(多くの場合、比較的単純な)Javaオブジェクト。
すべてのJavaBeansはPOJOですが、すべてのPOJOがJavaBeansではありません。
JavaBeanは、特定のプログラミング規則を満たすJavaオブジェクトです。
Martin Fowlerによると、POJOはビジネスロジックをカプセル化するオブジェクトであり、Bean(他の回答で既に述べた定義を除く)はデータを保持するコンテナーに過ぎず、オブジェクトで利用可能な操作は単にデータを設定および取得するだけです。
この用語は、Rebecca Parsons、Josh MacKenzie、および私が2000年9月の会議での講演の準備中に造られました。講演では、ビジネスロジックを通常のJavaオブジェクトにエンコードすることの多くの利点を指摘しましたエンティティBeanを使用します。私たちは、なぜ人々がシステムで通常のオブジェクトを使用することに反対するのか疑問に思い、単純なオブジェクトには派手な名前がなかったためだと結論付けました。だから私たちは彼らに1つを与えました、そしてそれは非常にうまくいきました。
Pojo-プレーンJavaオブジェクト
pojoクラスは、技術/フレームワークから完全に疎結合されたクラスです。このクラスはpojoクラスと呼ばれる技術/フレームワークapiから実装されず、技術/フレームワークapiから拡張されません。
pojoクラスはインターフェースを実装してクラスを拡張できますが、スーパークラスまたはインターフェースはテクノロジー/フレームワークであってはなりません。
例:
1。
class ABC{
----
}
ABCクラスはテクノロジー/フレームワークを実装または拡張しないため、これがpojoクラスです。
2。
class ABC extends HttpServlet{
---
}
サーブレットテクノロジーAPIから拡張されたABCクラス。これがpojoクラスではない理由です。
3。
class ABC implements Java.rmi.Remote{
----
}
ABCクラスはrmi apiから実装するため、これはpojoクラスではありません。
4。
class ABC implements Java.io.Serializable{
---
}
このインターフェースはJava言語の一部であり、テクノロジー/フレームワークの一部ではありません。これはpojoクラスです。
5。
class ABC extends Thread{
--
}
ここで、スレッドはJava言語のクラスでもあるため、これもpojoクラスです。
6。
class ABC extends Test{
--
}
testクラスがテクノロジー/フレームワークから拡張または実装する場合、ABCはTestクラスのプロパティを継承するため、pojoクラスでもありません。 Testクラスがpojoクラスでない場合、ABCクラスもpojoクラスではありません。
7。
今、この点は例外的なケースです
@Entity
class ABC{
--
}
@Entity
はhibernate apiまたはjpa apiによって与えられる注釈ですが、このクラスをpojoクラスとして呼び出すことができます。テクノロジー/フレームワークから与えられた注釈付きのクラスは、この例外的なケースではpojoクラスと呼ばれます。
POJO:他の外部サードパーティライブラリサポートなしで、基礎となるJDKを使用してクラスを実行できる場合、その呼び出されたPOJO
JavaBean:クラスにアクセサ(セッターとゲッター)を持つ属性のみが含まれる場合、それらはjavabeansと呼ばれます。通常、Java Beanにはビジネスロジックは含まれず、データを保持するために使用されます。
すべてのJavabeansはPOJOですが、すべてのPOJOはJavabeansではありません
POJOS
は特定の規則(getter/setter、引数なしのパブリックコンストラクタ、プライベート変数)で動作中(例:フォームによるデータの読み取りに使用されている)はJAVABEANS
です。
要約すると、類似点と相違点は次のとおりです
Java beans: Pojo:
-must extends serializable -no need to extends or implement.
or externalizable.
-must have public class . - must have public class
-must have private instance variables. -can have any access specifier variables.
-must have public setter and getter method. - may or may not have setter or getter method.
-must have no-arg constructor. - can have constructor with agruments.
すべてのJava BeanはPOJOですが、すべてのPOJOがJava Beanではありません。
上記の正式な定義を見てきました。すべての価値があるからです。
ただし、定義にこだわらないでください。ここでsenseを詳しく見てみましょう。
JavaBeansは、エンタープライズJavaアプリケーションで使用されます。このアプリケーションでは、ユーザーはデータやアプリケーションコードにリモートで、つまりサーバーから(Webまたはプライベートネットワーク経由で)ネットワークを介して頻繁にアクセスします。したがって、関連するデータは、ユーザーのコンピューターとの間でシリアル形式でストリーミングする必要があります。したがって、Serializableインターフェースを実装するには、Java EEオブジェクトが必要です。このJavaBeanの性質の大部分は、データがファイルシステムから読み取られる、またはファイルシステムに書き込まれるJava SEアプリケーションオブジェクトと同じです。 Javaクラスをさまざまなユーザーマシン/ OSの組み合わせからネットワーク経由で確実に使用するには、それらの処理に関する規則の採用も要求されます。したがって、これらのクラスを、プライベート属性、引数なしのコンストラクタ、および標準化されたゲッターとセッターを使用してパブリックとして実装するための要件。
Java EEアプリケーションは、JavaBeansとして実装されたもの以外のクラスも使用します。これらは、入力データの処理や出力データの整理に使用できますが、ネットワーク経由で転送されるオブジェクトには使用されません。したがって、上記の考慮事項は、Javaオブジェクトとして有効である場合には適用する必要はありません。これらの後者のクラスは、POJO-プレーンオールドJavaオブジェクトと呼ばれます。
全体として、Java Beanは、ネットワーク経由での使用に適合したJavaオブジェクトとして表示されます。
1995年以来、ソフトウェアの世界には、非常に多くの誇大宣伝があります-少なからぬハンバグはありません。