私はSpringの正しい使い方を理解しようとしています。構文的にではなく、その目的に関して。 Springを使用している場合、すべてのBeanインスタンス化コードをSpringコードで置き換える必要がありますか? Springを使用する場合と使用しない場合、Beanをインスタンス化するには
次のコードサンプルは、私のジレンマを理解するのに役立ちます。
List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
ClassA ca = new ClassA();
ca.setName(name);
caList.add(ca);
}
Springを構成すると、次のようになります。
List<ClassA> caList = new ArrayList<ClassA>();
for (String name : nameList) {
ClassA ca = (ClassA)SomeContext.getBean(BeanLookupConstants.CLASS_A);
ca.setName(name);
caList.add(ca);
}
個人的には、ここでのSpringの使用は不要なオーバーヘッドであると思います。
ClassA
の複数/可変実装があることを期待していないので、Dependency Injectionにはあまり適していません。後で、Spring構成を使用して自由に置き換えることができます。私は正しいと思いますか?そうでない場合、どこで間違っていますか?
そうです、Springはリストされたユースケースには不適切です。 Springは、外部の依存関係(JDBC接続のDAOへのプラグインなど)または構成(使用するデータベースの種類の指定など)の管理に適しています。この例では、Beanタイプが変更される可能性がある場合、インターフェースを使用してBeanを指定し、ファクトリを使用してBeanをインスタンス化します。 Springを使用して、使用するファクトリを指定し、Beanのインスタンス化に必要なクラスにそれを注入します。次に、いくつかの異なるタイプのBean(すべてがBeanインターフェースをサポートする)を作成するいくつかの異なるファクトリーを用意し、インストール(または更新)時にその適切なファクトリーを構成することができます。
レイヤー間でSpring(または別のDIシステム)を使用して、レイヤー内で直接インスタンス化します。
そのため、そのクラスのスコープを一部の(機能的に)外部システムに残すBeanを作成するクラスは、おそらくそのシステムまたは通信層によって定義され、DIを介して作成されます。アプリケーション層内で純粋に内部で使用するために作成された別のBeanは、コードの明確さと(大規模なシステムでも同様に)パフォーマンス上の理由から、直接作成されます。
beanの場合は、Springにビルドさせる必要があります(ファクトリBeanを提供できる場合を除いて、システムプロパティに依存する特定のサブクラスを返す必要がある場所で使用しました)。その場合は、@Configuration
および@Bean
アノテーションに関するドキュメントを参照してください)。 Beanではなく、Plain Old Java Objectの場合は、Springを使用して作成する必要はまったくありません。POJOは便利ですが、依存関係はありません。インジェクション、AOPラッパーなどは、Springが追加するものです。
基本的な決定は、それが本当にBeanであるか、それともたまたまBeanの規則(たとえば、メソッドの命名)に従う偶然の通常のオブジェクトであるかどうかです。あなたが与えた小さな例から、本当にそうであるとは思えません。
専門家が間違っているかもしれませんが訂正してください。
春のコンテキストでのBeanの全体的な概念は、Spring Containerがオブジェクトを処理することです。それは誕生であり、スコープはライフサイクルの死などです...それはオブジェクトの世話人のようなものです。それを必要とするアプリケーションはそれを注入します。
したがって、モジュールの設計中に決定を行うときは常に、Springフレームワークに注意を払ってほしいのか、それともライフサイクルがメソッドに囲まれている単純なオブジェクトなのかを考えます。
以前に示唆したように、daoオブジェクトjmsキューオブジェクトなどは重いので、Springフレームワークであるエキスパートに任せて処理するのが適切です。