「Bean」は、プロパティとゲッター/セッターを備えたJavaクラスであることを理解しました。
私が理解している限り、これはCに相当しstruct
ます。本当?
また、aと通常の間に実際の構文上の違いはありますか?
特別な定義や?JavaBean
class
Interface
基本的に、なぜこれに用語があるのですか?
また、Serializable
インターフェースはどういう意味ですか?
「Bean」は、プロパティとゲッター/セッターを備えたJavaクラスであることを理解しました。
私が理解している限り、これはCに相当しstruct
ます。本当?
また、aと通常の間に実際の構文上の違いはありますか?
特別な定義や?JavaBean
class
Interface
基本的に、なぜこれに用語があるのですか?
また、Serializable
インターフェースはどういう意味ですか?
JavaBeanは単なる標準です
Serializable
ます。それでおしまい。それは単なる慣習です。しかし、多くのライブラリがそれに依存しています。
に関してはSerializable
、APIドキュメントから:
クラスの直列化可能性は、java.io.Serializableインターフェースを実装するクラスによって有効になります。このインターフェースを実装しないクラスは、シリアル化または逆シリアル化された状態を持ちません。シリアライズ可能なクラスのすべてのサブタイプは、それ自体がシリアライズ可能です。シリアル化インターフェースにはメソッドやフィールドがなく、シリアル化可能であることのセマンティクスを識別するためだけに機能します。
言い換えれば、シリアル化可能なオブジェクトはストリームに書き込むことができ、したがってファイル、オブジェクトデータベース、実際には何でも書き込むことができます。
また、JavaBeanと別のクラスの間に構文上の違いはありません。クラスが標準に準拠している場合、そのクラスはJavaBeanです。
この標準では、事前定義された方法で定義したクラスインスタンスを使用して、ライブラリがプログラムで処理を実行できるため、この用語があります。たとえば、ライブラリが渡したオブジェクトをストリーミングしたい場合、オブジェクトはシリアル化可能であるため、ライブラリはそれを認識します(ライブラリでオブジェクトが適切なJavaBeansである必要があると仮定します)。
特別な音にするための用語があります。現実はそれほど神秘的ではありません。
基本的に、「Bean」:
java.io.Serializable
し、正しく実行します)。getFoo()
「Foo」プロパティのゲッター)があり、に関してSerializable
:それは、実装クラスが「シリアル化」に同意する(そしてそれが可能であることを意味する)ことをJavaに伝える「マーカーインターフェイス」(関数を宣言しないインターフェイス)に他なりません-変換するプロセスバイトのストリームへのインスタンス。これらのバイトはファイルに保存したり、ネットワーク接続を介して送信したりすることができ、JVM(少なくともオブジェクトのタイプを知っているもの)が後でオブジェクトを再構築できるようにするのに十分な情報を持っています-おそらく別のインスタンスでアプリケーション、または他のマシン全体でさえ!
もちろん、それを行うために、クラスは特定の制限に従わなければなりません。その中で最も重要なのは、すべてのインスタンスフィールドは、プリミティブ型(int、boolなど)、シリアル化可能なクラスのインスタンス、またはtransient
Javaがそれらを含めないようにマークされている必要があるということです。(もちろん、これは、transient
フィールドがストリームを介したトリップに耐えられないことを意味します。フィールドを持つクラスは、必要に応じてtransient
フィールドを再初期化する準備をする必要があります。)
これらの制限を順守できないクラスは実装すべきではありませんSerializable
(そして、IIRC、Javaコンパイラーはそれを実装することさえできません)。
JavaBeansは、非常に単純なコーディング規則に準拠したJavaクラスです。あなたがしなければならないのはすることだけです
java.io.Serializable
ます-オブジェクトの状態を保存しますJavaBeansのプロパティ
JavaBeanは、特定のプログラミング規則を満たすJavaオブジェクトです。
JavaBeanクラスは、Serializable
または
Externalizable
JavaBeanクラスには引数なしのコンストラクタが必要です
すべてのJavaBeanプロパティには、パブリックセッターメソッドとゲッターメソッドが必要です
すべてのJavaBeanインスタンス変数はプライベートである必要があります
JavaBeansの例
@Entity
public class Employee implements Serializable{
@Id
private int id;
private String name;
private int salary;
public Employee() {}
public Employee(String name, int salary) {
this.name = name;
this.salary = salary;
}
public int getId() {
return id;
}
public void setId( int id ) {
this.id = id;
}
public String getName() {
return name;
}
public void setName( String name ) {
this.name = name;
}
public int getSalary() {
return salary;
}
public void setSalary( int salary ) {
this.salary = salary;
}
}
例を挙げて説明します。
1.java.io.Serializableをインポートします
シリアル化については、ドキュメントを参照してください。
2.プライベートフィールド
外部クラスがこれらのフィールドを簡単に変更できないように、フィールドはプライベートにする必要があります。これらのフィールドに直接アクセスする代わりに、通常はゲッター/セッターメソッドが使用されます。
3.コンストラクター
引数のないパブリックコンストラクタ。
4.ゲッター/セッター
プライベートフィールドにアクセスして変更するためのgetterメソッドとsetterメソッド。
/** 1. import java.io.Serializable */
public class User implements java.io.Serializable {
/** 2. private fields */
private int id;
private String name;
/** 3. Constructor */
public User() {
}
public User(int id, String name) {
this.id = id;
this.name = name;
}
/** 4. getter/setter */
// getter
public int getId() {
return id;
}
public String getName() {
return name;
}
// setter
public void setId(int id) {
this.id = id;
}
public void setName(String name) {
this.name = name;
}
}
Java Beansは、コードを減らし、作業を増やすために使用されます...
Java Beansは、ランタイムの検出とアクセスのためのユニバーサルコントラクトとしてJavaEE全体で使用されます。たとえば、JavaServer Pages(JSP)は、ページ間またはサーブレットとJSP間のデータ転送オブジェクトとしてJavaBeansを使用します。JavaEEのJavaBeansActivationFrameworkは、JavaBeansを使用してMIMEデータ型のサポートをJavaEEに統合します。Java EE Management APIは、JavaEE環境で管理されるリソースのインストルメンテーションの基盤としてJavaBeansを使用します。
シリアル化について:
オブジェクトのシリアル化では、オブジェクトは、オブジェクトのデータ、およびオブジェクトのタイプとオブジェクトに格納されているデータのタイプに関する情報を含むバイトのシーケンスとして表すことができます。
シリアル化されたオブジェクトがファイルに書き込まれた後、ファイルから読み取って逆シリアル化できます。つまり、オブジェクトとそのデータを表すタイプ情報とバイトを使用して、オブジェクトをメモリに再作成できます。
Beanは永続化され、複数のサーバー間で転送されるため、プロジェクトを複数のサーバーにデプロイする場合にシリアル化が役立ちます。
JavaBeansは標準であり、その基本的な構文要件は他の回答によって明確に説明されています。
ただし、IMOは、単純な構文標準以上のものです。JavaBeansの本当の意味または使用目的は、標準に関するさまざまなツールサポートとともに、コードの再利用とコンポーネントベースのソフトウェアエンジニアリングを容易にすることです。つまり、開発者は既存のコンポーネント(クラス)を組み立てることで、コードを記述せずにアプリケーションを構築できます。 (または、ほんの少しのグルーコードを書く必要があります)。残念ながら、このテクノロジーは業界によって過小評価され、十分に活用されていません。これは、このスレッドの回答からわかります。
OracleのJavaBeansに関するチュートリアルを読むと、その理解を深めることができます。
Beanの概念に関するほんの少しの背景/更新。他の多くの回答には、実際には何が含まれていますが、その理由はそれほど多くありません。
これらは、GUIの構築の一部としてJavaで早い段階で発明されました。それらは、ツールが簡単に分解できるパターンに従っており、Beanの属性を編集できるようにプロパティパネルを作成できます。一般に、Beanプロパティは、画面上のコントロールを表します(x、y、width、height、text、..と考えてください)。
強く型付けされたデータ構造と考えることもできます。
時間の経過とともに、これらは同じタイプのアクセスを使用する多くのツールで役立つようになりました(たとえば、Hibernateを使用してデータ構造をデータベースに永続化する)
ツールが進化するにつれ、それらは注釈に向かって移動し、セッター/ゲッターの名前を引き離すことから離れました。現在、ほとんどのシステムはBeanを必要とせず、注釈付きのプロパティを持つプレーンオールドJavaオブジェクトを取得して、それらを操作する方法を指示できます。
今、私はBeanを注釈付きのプロパティボールと見なしています。これらは、実際には、Beanが持つ注釈に対してのみ役立ちます。
豆自体は健康的なパターンではありません。それらはすべてのプロパティを外部操作にさらすため、カプセル化を本質的に破壊します。また、使用されると、Bean内でコードを作成するのではなく、外部でBeanを操作するコードを作成する傾向があります(「don」に違反します)。オブジェクトにその値を要求するのではなく、オブジェクトに何かを実行するように要求してください」)。最小限のゲッターとセッターなしで注釈付きPOJOを使用すると、カプセル化が復元され、不変性の可能性があります。
ちなみに、これらすべてのことが起こっていたので、誰かがその概念をEnterpriseJavaBeansと呼ばれるものに拡張しました。これらは...違います。そして、それらは十分に複雑であるため、多くの人々はBeanの概念全体を理解していないと感じ、この用語の使用をやめました。これが、一般的にPOJOと呼ばれるBeanを聞く理由だと思います(すべてのJavaオブジェクトはPOJOであるため、技術的には問題ありませんが、誰かがPOJOと言うのを聞くと、ほとんどの場合、Beanパターンに従うものについて考えています)
ウィキペディアによると:
クラスには、パブリックのデフォルトコンストラクター(引数なし)が必要です。これにより、編集およびアクティベーションフレームワーク内で簡単にインスタンス化できます。
クラスプロパティは、get、set、is(getの代わりにブールプロパティに使用できます)、および標準の命名規則に従って他のメソッド(いわゆるアクセサーメソッドとミューテーターメソッド)を使用してアクセスできる必要があります。これにより、フレームワーク内のBean状態の自動検査と更新が簡単になります。フレームワークの多くには、さまざまなタイプのプロパティのカスタムエディターが含まれています。セッターは、1つまたは複数の引数を持つことができます。
クラスはシリアル化可能である必要があります。(これにより、アプリケーションとフレームワークは、VMやプラットフォームに依存しない方法で、Beanの状態を確実に保存、保存、および復元できます。)
詳細については、このリンクをたどってください。
質問の2番目の部分に関して、シリアル化は、オブジェクトを署名されたバイトのシーケンスとして格納するために使用される永続化メカニズムです。あまり正式ではありませんが、オブジェクトの状態を格納するため、後でデシリアライズによって取得できます。
Java Beanは、次の規則に従う必要があるJavaクラス(概念)です。
これは再利用可能なソフトウェアコンポーネントです。多くのオブジェクトを1つのオブジェクトにカプセル化できるため、複数の場所から同じオブジェクトにアクセスでき、コードの保守を容易にするためのステップになります。
これらはシリアライズ可能で、引数がゼロのコンストラクターを持ち、getterメソッドとsetterメソッドを使用してプロパティにアクセスできます。「Bean」という名前は、Java用の再利用可能なソフトウェアコンポーネントを作成することを目的としたこの標準を包含するために付けられました。ウィキペディアによると 。
アプリケーションのバックボーンを形成し、SpringIoCコンテナーによって管理されるオブジェクトはBeanと呼ばれます。Beanは、Spring IoCコンテナによってインスタンス化、アセンブル、またはその他の方法で管理されるオブジェクトです。それ以外の場合、Beanはアプリケーション内の多くのオブジェクトの1つにすぎません。SpringIoCによると 。
Beanは、プロパティ、メソッド、およびイベントのJavaBeanガイドライン(デザインパターンとも呼ばれる)に従うメソッド名を持つJavaクラスです。。したがって、プロパティ定義の一部ではないBeanクラスのパブリックメソッドはすべてBeanメソッドです。最低限、Javaクラスは、プロパティを唯一のメンバーとして(もちろん、パブリックゲッターとセッターを伴う必要があります)、パブリックメソッドを唯一のメンバーとして、または1つのパブリックイベントリスナー登録メソッドをJavaBeanとして使用します。さらに、プロパティは読み取り専用プロパティ(getterメソッドはあるがsetterはない)または書き込み専用プロパティ(setterメソッドのみがある)のいずれかです。Java Beanは、Beanboxツールまたはコンテナに表示されるパブリッククラスである必要があります。コンテナはそれをインスタンス化できなければなりません。したがって、パブリックコンストラクタも必要です。JavaBeans仕様コンテナがインスタンス化するために、明示的またはデフォルトのパブリックゼロ引数コンストラクタをBeanに持たせる必要はありません。シリアル化されたインスタンスを含むファイル(拡張子.ser)を提供できる場合、Beanboxツールはそのファイルを使用してプロトタイプBeanをインスタンス化できます。それ以外の場合、Beanには、明示的またはデフォルトのパブリックゼロ引数コンストラクターが必要になります。
Beanがインスタンス化されると、JavaBean API(java.beans。*)は、Beanをイントロスペクトし、メソッドを呼び出すことができます。インターフェイスBeanInfoを実装するクラスまたはBeanInfo実装を拡張するSimpleBeanInfoクラスが利用できない場合、イントロスペクションでは、リフレクション(暗黙的なイントロスペクション)を使用してターゲットBeanでサポートされるメソッドを調査し、単純なデザインパターン(ガイドライン)を適用して推論します。これらのメソッド、どのプロパティ、イベント、およびパブリックメソッドがサポートされているか。インターフェイスBeanInfo(Bean Fooの場合はFooBeanInfoという名前にする必要があります)を実装するクラスが使用可能な場合、APIは暗黙的なイントロスペクションをバイパスし、このクラスのパブリックメソッド(getPropertyDescriptor()、getMethodDescriptors()、getEventSetDescriptors())を使用して情報。SimpleBeanInfoを拡張するクラスが利用可能な場合、SimpleBeanInfoパブリックメソッド(getPropertyDescriptor()、getMethodDescriptors()、getEventSetDescriptors())のどれがオーバーライドされるかに応じて、それらのオーバーライドされたメソッドを使用して情報を取得します。オーバーライドされないメソッドの場合、デフォルトで対応する暗黙的なイントロスペクションが使用されます。Beanは、暗黙的なイントロスペクションが実行されていない場合でも、とにかくインスタンス化する必要があります。したがって、パブリックゼロ引数コンストラクターの要件。ただし、もちろん、SerializableまたはExternalizableインターフェイスは認識される必要はありません。ただし、Java Beanの仕様では、「内部状態を保存したいだけで、それについて考えたくない小さなBeanの一般的なケースでも「些細な」ものにしたいと考えています。」したがって、すべてのBeanはSerializableまたはExternalizableインターフェースを実装する必要があります。
全体として、JavaBeansの仕様は、Beanを構成するものについては難しくも速くもありません。「JavaBeansコンポーネントの記述は驚くほど簡単です。特別なツールやインターフェースを実装する必要はありません。Beanの記述は、特定のコーディング規則に従うだけです。必要なのは、クラスを次のようにすることだけです。 Bean — Beanを使用するツールは、Beanを認識して使用できるようになります。」自明なことに、次のクラスでさえJavaBeanです。
public class Trivial implements java.io.Serializable {}
以下で説明するBeanは、上記のJava SEバージョン(JavaBeans)のJavaEEバージョンです。これらの説明は、上記で説明した基本的な考え方をさらに示しています。
春の豆
たとえば、Beanコンストラクターにはいくつかのパラメーターがあります。いくつかが単純なタイプであると仮定します。コンテナは、それらに割り当てる値を認識していない可能性があります。たとえそうだとしても、結果のインスタンスは再利用できない可能性があります。ユーザーがSpringBeanのようにアノテーションやxml構成ファイルなどで構成(値を指定)できる場合にのみ意味があります。そして、いくつかのパラメータがクラスまたはインターフェースタイプであると仮定します。繰り返しますが、コンテナはそれに割り当てる値を知らない場合があります。ユーザーが注釈やxml構成ファイルなどで構成(特定のオブジェクトを指定)できる場合にのみ意味があります。ただし、Springでも(xml構成ファイルを介して)、特定のオブジェクト(文字列名を含む)をコンストラクター引数(コンストラクター引数の属性または要素)に割り当てることはタイプセーフではなく、基本的にリソースインジェクションのようなものです。他のSpringBean(コラボレーターと呼ばれ、コンストラクター引数要素の要素を介して)への参照を作成することは、基本的に依存性注入であり、したがってタイプセーフです。明らかに、依存関係(コラボレーターBean)には、パラメーターが挿入されたコンストラクターがある場合があります。これらの注入された依存関係には、パラメーターなどを含むコンストラクターがある場合があります。このシナリオでは、最終的に、コンストラクターへの依存性注入を介して他のコラボレーションBeanを構築する前に、コンテナーがnew MyBean()を呼び出すだけでインスタンス化できる、いくつかのBeanクラス(MyBean.classなど)が必要になります。パブリックゼロ引数コンストラクターを持つBean。コンテナが依存性注入をサポートしていない場合や、Springのように、いくつかのアノテーションまたはxml構成ファイルを介してコンストラクターに単純型の値を割り当てることができない場合を想定します。Beanコンストラクターはパラメーターを持つべきではありません。Spring Beanアプリケーションでさえ、パブリックのゼロ引数コンストラクターを持つためにいくつかのBeanが必要になります(たとえば、Springアプリケーションにコンストラクター引数として単純な型だけを持つBeanがないシナリオでは)。
JSFマネージドBean
JSFマネージドBeanはWebコンテナで実行されます。これらは、@ManagedBeanアノテーションまたはアプリケーション構成リソースファイルmanaged-bean.xmlのいずれかを使用して構成できます。ただし、リソースインジェクション(タイプセーフではない)のみを介したインジェクションをサポートします。コンストラクターへの注入には適していません。JSF仕様マネージドBeanには、パブリックのゼロ引数コンストラクターが必要です。さらに、「この仕様のバージョン2.3以降、このセクションで指定されているマネージドBean機能の使用は強く推奨されていません。同じ問題を解決するためのより優れた、よりまとまりのある統合ソリューションは、JSR-365で指定されているContexts and Dependency Injection(CDI)を使用することです。 CDI仕様はManagedBeans仕様を採用しており、これはWeb層だけでなく、JEEプラットフォームのすべてのコンテナーに適用されます。したがって、WebコンテナーはCDI仕様を実装する必要があります。
マネージドBean
これは、 ManagedBean仕様からの抜粋です。 「マネージドBeanは、最小限の要件を持つコンテナ管理オブジェクトであり、頭字語「POJOs」(Plain Old Java Objects)で知られています…これらは、JavaSEプラットフォームにあるJavaBeansコンポーネントモデルのJavaEEプラットフォーム拡張バージョンと見なすことができます。 …。読者は、マネージドBeanがJavaServer Faces(JSF)テクノロジーに見られる同名の機能の前身を持っていることを見逃すことはありません…この仕様で定義されているマネージドBeanは、JSFに見られるものの一般化を表しています。特に、Managed Beansは、Webモジュールだけでなく、JavaEEアプリケーションのどこでも使用できます。たとえば、基本コンポーネントモデルでは、Managed Beansは引数のないコンストラクターを提供する必要がありますが、CDI(JSR-299)などのManagedBeansに基づく仕様は 明確に定義されたルールに従っている限り、その要件を緩和し、マネージドBeanがコンストラクターにさらに複雑なシグニチャーを提供できるようにすることができます...マネージドBeanは、最終クラス、抽象クラス、非静的内部クラスであってはなりません。 。マネージドBeanは、通常のJavaBeanコンポーネントとは異なり、シリアライズできない場合があります。」したがって、マネージドBean(POJOまたはPOJO Beanとも呼ばれる)の仕様では、CDIのように拡張できます。
CDI Beans
CDI仕様は、マネージドBeanを次のように再定義します。JavaEEで実行する場合、トップレベルのJavaクラスは、要件を満たしている場合、マネージドBeanです。
•内部クラスではありません。•非抽象クラスであるか、@Decoratorという注釈が付けられています。•javax.enterprise.inject.spi.Extensionを実装していません。•@Vetoedの注釈が付けられていないか、@Vetoedの注釈が付けられたパッケージに含まれていません。•適切なコンストラクターがあります。クラスにパラメーターのないコンストラクターがあるか、クラスが@Injectという注釈の付いたコンストラクターを宣言しています。
これらの条件を満たすすべてのJavaクラスはマネージドBeanであるため、マネージドBeanを定義するために特別な宣言は必要ありません。または
他のJavaEE仕様によってマネージドBeanとして定義されている場合、および
•EJBコンポーネントを定義するアノテーションが付けられたり、ejb-jar.xmlでEJBBeanクラスとして宣言されたりすることはありません。
Spring Beanとは異なり、単純型のコンストラクターはサポートされていません。これは、Springやアノテーションなどのxml構成ファイルを使用した構成をサポートしている場合に可能になる可能性があります。
EJB
EJBはEJBコンテナで実行されます。その仕様「セッションBeanコンポーネントはマネージドBeanです。」「クラスには、引数をとらないパブリックコンストラクタが必要です」と、セッションBeanとメッセージ駆動型Beanの両方について述べています。さらに、「セッションBeanクラスはSessionBeanインターフェースまたはSerializableインターフェースを実装する必要はありません。」JSF Beanと同じ理由で、EJB3依存性注入は基本的にリソース注入であるため、JSF Beanは、引数付きのコンストラクター、つまり依存性注入をサポートしません。ただし、EJBコンテナーがCDIを実装する場合、「オプション:クラスにInjectアノテーションが付けられた追加のコンストラクターは、「セッションBeanとメッセージ駆動型Beanの両方について、次のように述べています。「CDI Beanアーカイブにパッケージ化され、javax.enterprise.inject.Vetoedアノテーションが付けられていないEJBは、CDI対応と見なされます。豆。」</p>
Java Beanは、次の3つの基準を満たす任意のJavaクラスです。
serialVersionUIDフィールドは、オブジェクトの状態を維持するために重要であることに注意してください。
以下のコードはBeanとしての資格があります。
public class DataDog implements java.io.Serializable {
private static final long serialVersionUID = -3774654564564563L;
private int id;
private String nameOfDog;
// The constructor should NOT have arguments
public DataDog () {}
/** 4. getter/setter */
// Getter(s)
public int getId() {
return id;
}
public String getNameOfDog() {
return nameOfDog;
}
// Setter(s)
public void setId(int id) {
this.id = id;
}
public void setNameOfDog(String nameOfDog) {
this.nameOfDog = nameOfDog;
}}
JavaBeansには引数なしのコンストラクター要件があることが、上記で6〜7回繰り返されました。
これは間違っています。特にJavaSpringのコンテキストでは、そのような要件はありません。
また、JavaBeanns API( https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/)を記述している仕様のバージョン(1.01)には、その要件についての言及はありません。 )。さらに、この仕様では、次のコンテキストで「nullコンストラクター」について2回しか言及していません。「各カスタマイザーにはnullコンストラクターが必要です。」「各PropertyEditorにはnullコンストラクターが必要です。」
したがって、仕様の作成者が「nullコンストラクタ」という用語を知らないか、使用する意思がないようですが、JavaBeans自体についてはまだ言及されていません。
JavaBeanを理解するには、次の点に注意する必要があります。
JavaBeanは概念的なものであり、特定のもののクラスを表すことはできません
JavaBeanは、再利用可能なソフトウェアコンポーネントの操作で視覚化できる開発ツールです。
JavaBeanはSunJavaBeans仕様に基づいており、再利用可能なコンポーネントにすることができます。その最大の特徴は、再利用性です。
POJO(プレーンオールドJavaオブジェクト):POJOは通常のJavaオブジェクトであり、Java言語によって強制されるもの以外の制限はありません。
シリアル化:オブジェクトの状態を保存し、ネットワークを介して送信するために使用されます。オブジェクトの状態をバイトストリームに変換します。デシリアライズと呼ばれるプロセスによって、バイトストリームからJavaオブジェクトを再作成できます。
クラスにjava.io.Serializableインターフェースを実装させます。そして、ObjectOutputStreamクラスのwriteObject()メソッドを使用して、シリアル化を実現します。
JavaBeanクラス:これは特別なPOJOであり、いくつかの制限(または規則)があります。
Springのような多くのフレームワークはJavaBeanオブジェクトを使用します。
C / Golangに精通している場合、CbeanまたはGobeanにはstruct
キーワードがあり、開発者は複雑なOOPキーワードを記述せずに構造型を簡単に定義できるため、聞いたことはありません。
type User struct {
Name string
Age int
}
var user User
user.Name = "name"
user.Age = 18
var bytes, err = json.Marshal(user)
型が不足しているのはJavaの間違いでstruct
あり、開発者はこのひどい不足に気づきます。
次に、Java Beanは、クラスメンバーへの安全でないアクセスについて、エディタやコンパイラが泣いたり叫んだりしないclass
ふりをするためのもう1つの退屈なルールとして発明されました。struct
Beansアプリケーションのバックボーンを形成し、SpringIoCコンテナーによって管理されるオブジェクトはBeansと呼ばれます。Beanは、Spring IoCコンテナによってインスタンス化、アセンブル、またはその他の方法で管理されるオブジェクトです。これらのBeanは、コンテナーに提供する構成メタデータを使用して作成されます。
Java-Beansを理解したい場合は、最初にソフトウェアコンポーネントを理解する必要があります。
ソフトウェアコンポーネント
ソフトウェアコンポーネントは、特定の操作を実行するアプリケーションの一部です。ソフトウェアコンポーネントもサービスの一部にすることができます。
コンポーネントは次のとおりです。
Java Beans(Enterprise Beans)
Java Beansは、大規模なシステムを管理するための概念です。それが彼らが標準化を必要とする理由です。
実際には、Beanは使いやすいオブジェクトにすぎません。それらをシリアル化するということは、それらを簡単に永続化できることを意味します(簡単に回復できる形式で保存します)。
実世界でのBeanの一般的な使用法:
したがって、実際には、Beansは、Javaオブジェクトから何かが動作し(シリアル化)、特定の方法でそれを変更する(プロパティのセッター)方法を提供することを期待するための単なる慣習/標準です。
それらの使い方はあなたの発明に過ぎませんが、私が上に挙げた最も一般的なケースです。
Java Beanは、JavaBeansアーキテクチャのコンポーネントまたは基本的な構成要素です。JavaBeansアーキテクチャは、コンポーネントベースのアプローチの再利用性と相互運用性の恩恵を受けるコンポーネントアーキテクチャです。
有効なコンポーネントアーキテクチャでは、おそらくさまざまなベンダーによって提供されるソフトウェアビルディングブロック(この場合はBean)からプログラムをアセンブルでき、アーキテクト/開発者がコンポーネント(Bean)を選択し、その機能を理解し、組み込むことができるようにする必要があります。アプリケーションにそれを。
クラス/オブジェクトはJavaのようなOOP言語の基本的な構成要素であるため、 JavaBeansアーキテクチャのBeanであるための自然な候補です。
プレーンなJavaクラスをJavaBeanに変換するプロセスは、実際には、再利用可能で相互運用可能なコンポーネントにすることに他なりません。これは、次のような機能を持つJavaクラスに変換されます。
JavaクラスをJavaBeanと呼ぶために、上記のすべての機能を備えている必要はありません。代わりに、コンテキストに関連する上記のサブセットを実装することを意味します(たとえば、特定のフレームワークのBeanはカスタマイザーを必要としない場合があり、他のBeanはバインドおよび制約されたプロパティを必要としない場合があります)。
上記の利点を享受するために、Javaのほとんどすべての主要なフレームワークとライブラリは暗黙的にJavaBeansアーキテクチャに準拠しています。
Spring @Beanアノテーションは、メソッドがSpringコンテナによって管理されるBeanを生成することを示します。
詳細:https ://www.concretepage.com/spring-5/spring-bean-annotation