Springを使用してBeanをインスタンス化しない場合


13

私はSpringの正しい使い方を理解しようとしています。構文的にではなく、その目的の観点から。Springを使用している場合、SpringコードはすべてのBeanインスタンス化コードを置き換える必要がありますか?Beanをインスタンス化するために、Springを使用する場合と使用しない場合

次のコードサンプルが私のジレンマを理解するのに役立つかもしれません:

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を使用することは不必要なオーバーヘッドだと思います、なぜなら

  1. コードは読みやすく、理解しやすいです。
  2. の複数の実装やさまざまな実装があることを期待していないため、Dependency Injectionにはあまり適していません。SpringのClassA設定を後から自由に置き換えたいと思います。

私は正しいと思っていますか?そうでない場合、どこで間違っていますか?

回答:


14

あなたは正しい、あなたがリストしたユースケースにはSpringは不適切です。Springは、外部依存関係(DAOへのJDBC接続のプラグインなど)または構成(使用するデータベースタイプの指定など)の管理に適しています。この例では、Beanタイプが変更される可能性がある場合、インターフェースを使用してBeanを指定し、Factoryを使用してBeanをインスタンス化します。Springを使用して、使用するファクトリを指定し、それをBeanのインスタンス化に必要なクラスに注入します。その後、いくつかの異なるタイプのBean(すべてがBeanインターフェースをサポートする)を作成するいくつかの異なるファクトリーを作成し、インストール(または更新)時に適切なものを構成できます。


9

レイヤー間でSpring(または別のDIシステム)を使用し、レイヤー内で直接インスタンス化します。
そのため、そのクラスまたは通信層によって定義される可能性のある何らかの(機能的に)外部システムに、そのクラスのスコープを残すBeanを作成するクラスは、DIを介して作成されます。アプリケーション層内での内部使用のために純粋に作成された別のBeanは、コードの明確さと(同様に重要な)パフォーマンス上の理由から、直接作成されます。


これは私にとっても有効な答えです!悲しいことに、私は1つの答えしか選択できません。
リシャブ

1

もしそうであればBeanは、あなたは工場出荷時の豆を供給することができ除い春は(それを構築させてください-あなたは上のドキュメントを参照してください-私は特定のサブクラスに依存するシステムプロパティ上を返すために必要な場合ということ使ってきた@Configuration@Bean注釈あなたがそれをしている場合)。Beanではなく、単なるPlain Old Java Objectである場合は、Springを使用して作成する必要はまったくありません。POJOは便利ですが、依存性の注入、AOPラッパーなどはSpringが追加するものなので、取得しません。

基本的な決定は、それが実際にBeanであるかどうか、またはたまたまいくつかのBean規則(メソッドの命名など)に従う偶然の単なるオブジェクトであるかどうかです。あなたが与えた小さな例から実際にどれが当てはまるかは推測できません。


こんにちはDonal、ClassAがビジネスロジックが豊富なドメインクラスである場合、あなたの答えは同じでしょうか?
サミールパティル

0

私は間違った専門家かもしれませんが修正してください。

SpringコンテキストでのBeanの概念全体は、Spring Containerがオブジェクトを処理することです。それは誕生であり、スコープライフサイクルの死などです...それはオブジェクトの世話人のようです。それを必要とするアプリケーションはそれを注入します。

したがって、モジュールの設計中に決定を下す際には、Springフレームワークに注意を払うか、ライフサイクルがメソッドに囲まれている単純なオブジェクトかを常に検討してください。

以前に提案したように、daoオブジェクトjms queuesオブジェクトなどは重いので、Springフレームワークの専門家に任せてください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.