1

たとえば、ContainingClass と DependencyClass (およびそのインターフェイス) がある場合:

public class ContainingClass {
    IDependencyClass d;
    public ContainingClass(IDependencyClass d){
        this.d = d;
    }
}

それらは十分に分離されています。この時点で、明らかにコンストラクターを使用してそれらを接続できます。春のコンテキストでわざわざそれらを定義するのはなぜですか?

Bean を管理するためにスプリング コンテナーを使用する利点について教えてください。前もって感謝します。

また、Springコンテナを使いすぎると、コンテナのメンテナンスやコードのリファクタリングがかなり難しくなると思います。ではない？

4

2 に答える 2

1

コンテナは通常、すべてのオブジェクトのインスタンス化を担当する最上位エンティティとして使用されます。最終的に解決しなければならない問題を解決し、すべてのオブジェクトをまとめて新しいものにし、アプリケーションに命を吹き込む必要があります。

依存性注入フレームワークが登場する前は、この問題を解決するために、複数のオブジェクトを結び付ける役割を担う個別の Factory クラスを用意していました。大規模なアプリケーションでは、これにより、一連のオブジェクトに対して "new" を呼び出すだけの不要な定型クラスが多数作成されました。Spring を使用すると、アプリケーションからその懸念を本質的に取り除くことができます。

非常に小さなアプリケーションの場合、おそらくアプリケーションを構築する必要性を感じることはなく、Spring コンテナーを使用するのはおそらくやり過ぎです。しかし、大規模なアプリケーションの場合、Spring のようなコンテナーを使用すると定型的なカットが削減され、アプリケーションのコンテキスト全体を毎回配線することなく、テスト目的でアプリケーションの一部を簡単に配線できます。

さらに、依存性注入コンテナーは、特定のコーディング スタイルを推奨します。これにより、一般的に、よりテストしやすいシステムにつながります。つまり、コンストラクターで依存性を新規作成するのではなく、依存性を注入します。これにより、データベース接続などをモック オブジェクトに簡単に置き換えることができます。

ContainingClass特定の質問に対する答えは、両方をインスタンス化する方法とのインスタンスを見つける場所を知っているアプリケーションに他のクラスが存在する必要があるということですIDependencyClass。Spring がこれを行うことができます。または、自分でそれを行うクラスを作成する必要があります。

于 2013-08-30T23:29:03.157 に答える
0

考慮すべき 3 つのポイントを次に示します。

  1. そもそもSpringを使うのは理にかなっていますか? 多くのクラスとパッケージを含む大規模な Java Web アプリケーションの場合 - はい (考えられる代替案を検討したと仮定して)。それが数行の Java App である場合は、おそらく違います。

  2. 一貫性。プロジェクトの残りの部分が Spring であり、XML で Bean として構成されている場合は、おそらくそれに固執するでしょう。他にどのように行われていますか？ゼロから始めて、Spring MVC を使用していますか? その後、そのパターンに固執してください。Spring のドキュメントで多くの例を見ることができます。

  3. あなたの2つのクラスはどのように分離されていますか。たとえば、あなたContainingClassがサービス層のサービスでありIDependencyClass、データ アクセス層の DAO である場合、ほとんどの場合、それらを個別に構成したままにして、Spring にインジェクションを実行させます。特に、IDependencyClass別のコンテキストで を使用することを計画している場合や、気づかずに切り替えることができるようにするContainingClass場合 (たとえば、基になるアクセス レイヤーが変更された場合)。

また、注釈ベースの構成を使用することを検討してください。これにより、個別の XML ファイルの必要性が大幅に削減され、(適切に行われた場合) XML と Java コードを切り替える必要があるため、コードのトレースが容易になります。

于 2013-08-30T23:51:10.373 に答える