回答:
JavaBeanは特定の規則に従います。ゲッター/セッターの命名、デフォルトのパブリックコンストラクター、シリアル化可能など。詳細については、JavaBeansの規約を参照してください。
POJO(plain-old-Java-object)は厳密には定義されていません。特定のフレームワークと互換性を持たせるために特定のインターフェイスを実装したり、特定の基本クラスから派生したり、特定の注釈を利用したりする必要のないJavaオブジェクトであり、任意のものにすることができます(多くの場合比較的単純)。 Javaオブジェクト。
すべてのJavaBeanはPOJOですが、すべてのPOJOがJavaBeanであるとは限りません。
JavaBeanは、特定のプログラミング規則を満たすJavaオブジェクトです。
Serializable
。
Martin Fowlerによると、POJOはビジネスロジックをカプセル化するオブジェクトであり、Bean(他の回答ですでに定義されている定義を除く)は、データを保持するためのコンテナーであり、オブジェクトで使用できる操作はデータを設定および取得するだけです。
この用語は、2000年9月の会議でのレベッカパーソンズ、ジョシュマッケンジー、および私が講演の準備をしているときに生まれました。この講演では、エンティティBeanを使用するのではなく、ビジネスロジックを通常のJavaオブジェクトにエンコードすることの多くの利点を指摘していました。なぜシステムで通常のオブジェクトを使用することに反対するのか疑問に思い、単純なオブジェクトにはファンシーな名前が欠けていたためだと結論付けました。だから私たちは彼らに1つを与えました、そしてそれは非常にうまくキャッチされました。
Pojo-プレーンな古いJavaオブジェクト
pojoクラスは特別なものを持たない通常のクラスであり、テクノロジー/フレームワークから完全に疎結合されたクラスです。このクラスはテクノロジー/フレームワークから実装されておらず、テクノロジー/フレームワークAPIから拡張されていません。このクラスはpojoクラスと呼ばれます。
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クラスと呼ばれます。
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であるとは限りません。
上記の正式な定義を見てきましたが、それらはすべて価値があります。
しかし、定義にこだわりすぎないでください。ここで物事の感覚をもっと見てみましょう。
JavaBeansはエンタープライズJavaアプリケーションで使用され、ユーザーは頻繁にリモートから、つまりサーバーを介して(Webまたはプライベートネットワーク経由で)ネットワーク経由でデータやアプリケーションコードにアクセスします。したがって、関連するデータは、ユーザーのコンピューターとの間でシリアル形式でストリーミングする必要があります。そのため、Java EEオブジェクトがSerializableインターフェースを実装する必要があります。これだけのJavaBeanの性質は、データがファイルシステムから読み取られたり、ファイルシステムに書き込まれたりするJava SEアプリケーションオブジェクトと同じです。さまざまなユーザーマシン/ OSの組み合わせからネットワークを介してJavaクラスを確実に使用するには、それらの処理に関する規則の採用も必要です。したがって、これらのクラスを、プライベート属性、引数なしのコンストラクター、および標準化されたゲッターとセッターを使用して、パブリックとして実装するための要件。
Java EEアプリケーションは、JavaBeansとして実装されたクラス以外のクラスも使用します。これらは、入力データの処理や出力データの整理に使用できますが、ネットワーク経由で転送されるオブジェクトには使用されません。したがって、Javaオブジェクトとして有効であることを禁止するために、上記の考慮事項をそれらに適用する必要はありません。これらの後者のクラスは、POJO(Plain Old Java Object)と呼ばれます。
全体として、Java Beanはネットワーク上での使用に適合した単なるJavaオブジェクトと見なすことができます。
1995年以来、ソフトウェアの世界では、非常に多くの誇大広告があり、それは少なからずあります。