2012-04-16 4 views
3

私のピアは常に、どのオブジェクトの新しいインスタンスを作成するためにSpringを使用するよう強制します。私の理解によると、Springはビジネスオブジェクトをより効率的に管理するためのプラットフォームを提供しています。 Springは、アーキテクチャをよりモジュラで柔軟にします。春の有無にかかわらず、パフォーマンスは改善されていますか?

私は春の豆を使用しないと感じる場合があり、新しいオブジェクトを作成する一般的な方法に行く場合があります。しかし、私の同僚は、パフォーマンス改善の言い訳をすることによって、常にそれを実行するように強制します。私は、パフォーマンスの要因が言及されている場所で、春に関連する記事を見つけることはありません。

質問:"new"演算子を使用して新しいインスタンスを作成する場合と比較して、パフォーマンスを向上させるかどうかにかかわらず、オブジェクトの作成にSpring Beanを使用している場合。

+2

正確にハンドリングするオブジェクトを教えてください。 –

+0

別の層の間でデータキャリアとして使用されるJavaコレクションを拡張することによるカスタムコレクションクラス..もし私の同僚がモジュール性について不平を言うならば、しかし、その理由がパフォーマンスであれば、パフォーマンスがどのように向上するかを知る必要があります。私は春について多くの知識を持っていないので、私は質問を投稿します。 – Shashi

+1

クイックサンプルは、newを使用してスタックトレースを比較し、springを使用してスタックトレースを比較してください。後者は10または数百行になり、おそらく5つ以上のクラスが含まれます。新しいクラスは常により速く、永遠になります。 –

答えて

2

あなたは合理的に考えると、どのように春が速くなることができますか?それはあなたのコードの上にラッパーです。また、それは適用可能なデフォルトのコンストラクタ/オーバーロードコンストラクタを経由します。

import demo.dependency.injection。IAccount;

public class SavingAccount implements IAccount { 
public static int SAVING_INT = 5; 

public SavingAccount() { 
    System.out.println("Default constructor invoked!!"); 
} 

@Override 
public int calculateInterest(int amount, int duration) { 
    return (amount*duration*SAVING_INT)/100; 
} 

}

豆の設定:アプリケーション・コンテキストを使用してBeanをロードすると、それは我々が以外理解する必要があり、ここで、しかし

ApplicationContext context = new FileSystemXmlApplicationContext("/Beans/SpringDemo.xml"); 
Account myAccount = (Account)context.getBean("FixedAccount"); 


Default constructor invoked!! 

を出力します

<!-- Fixed Account --> 
<bean id="FixedAccount" class="demo.dependency.injection.impl.FixedAccount"> 
</bean> 

パフォーマンスには他の利点があります。 のように - DI - 管理性

だからパフォーマンスの理由は正当ではないと思います。

それ以外: Spring IOCフレームワークは、Spring Bean構成を使用してインスタンスを作成する方法を提供します。ただし、new演算子を使用してインスタンスを作成することを停止するわけではありません。

私はあなたの代わりに春の豆新しいを使用することを選択したことの例を与えたいと思います。

あなたのWebアプリケーションでは、ビジネスロジックのためのさまざまなメソッドを持つシングルトンBeanがあり、操作ごとに新しいオブジェクトインスタンスが必要な場合があります(メソッドレベルの変数はスレッドセーフです)。

シングルトンBeanにプロトタイプBeanがある場合、シングルトンBeanが呼び出されたときに一度だけ呼び出されるためです。完全な理解のためにこれを行ってください。

http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch04s04.html

0

Springを使用してBeanを作成することは、すべてオブジェクトをうまく管理することです。Beanを使用してIOC(Inversion of Control)とAOPサポートを使用できます。

新しいオブジェクトを作成するには、newを使用するか、springを使用するかは同じです(パフォーマンス上の問題はないと思いますが、springを使用すると、後でもっと整理され柔軟になります)。

もうひとつSpringは、シングルトンやファクトリメソッドなどのような様々なデザインパターンもサポートしています。

1

春を使用している間、生のパフォーマンスはアプリを作成する際に気になるものではありません。それが成長するにつれてコードの保守性が向上します。 したがって、ファクトリメソッドを使用してオブジェクトをインスタンス化して、&を作成してビジネスコードを実行する負担からユーザを分離することをお勧めします。 IOCは、春の中心的な教えであり、関与していないオブジェクトの作成に役立ちます。 工芸品のベストプラクティスについては、blog postをご覧ください。

3

私は春のアプリケーションコンテキストの初期解釈はそれを遅らせる可能性がどこを打つだけパフォーマンスが(それができるかマイナーまたはメジャー)起動時になると思います。しかしその後、Springはすべてのメタデータを手に入れているので、標準的なケースでは測定可能なオーバーヘッドになるはずです。

したがって、デスクトップ上で通常スタートアップのパフォーマンスが重要な場合は、大規模で複雑なアプリケーションで認識されるパフォーマンスに影響を与える可能性があります。サーバサイドアプリケーションでは起動がそれほど重要ではなく、アプリケーションがどのように負荷をかけて動作するかが重要なので、ほとんど無視できます。

Springと非Springの唯一の違いは、SpringがメタデータとAOPの内容をメモリに作成してキャッシュする必要があるため、デフォルトのメモリ消費に部分的な影響があることです。

3

Springフレームワークではなく、それは、疎結合アプリケーションを作成するためのものである、豆を作るの性能を向上させるためではありません。これを達成するために、依存性注入と反転制御を使用します。

ここではは何ができるのですか?

  1. http://www.wrox.com/WileyCDA/Section/Why-Use-the-Spring-Framework-.id-130098.html
  2. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/overview.html
  3. http://orangeslate.com/2006/11/10/five-advantages-of-spring-framework/

私はそれがパフォーマンスは "新しい" 演算子を使用して新しいインスタンスを作成するに比較し改善するかどうかのオブジェクトを作成するための春の豆を使用していた場合。

通常はいいえ、それはです。春の場合でも、コンストラクタコンストラクタかリフレクションが必要です。デフォルトでは、Spring Beanはシングルトンなので、一度だけ作成されます。 2回目にアクセスする方が速いかもしれません。しかし、あなただけがそのために春を使用していないことを確認してください。

13

スプリングは他のどのようなツールでもあります。適切に適用すると、利点があります。不適切に適用されると、純粋なオーバーヘッドにすぎません。

これは、私がSpringといつも見ている共通の出来事です。プロジェクトは、すべてがSpring Beanでなければならないと命令します。これは、何か簡単なことをしようとしているときに、開発アーチファクトの点で膨大な量のオーバーヘッドをもたらす。

Springを使用している多くのアプリケーションで見逃している重要なポイントは、デザイナー/アーキテクトの側でオブジェクト指向の経験や知識が一般的に欠けていることです。彼らは春には快適です。したがって、すべてが春でなければなりません。この状況は、アプリケーションの全体的なクラス階層を調べることでよくわかります(Spring Beanを理解するUMLツールがわからない場合)。ほとんどの場合、ほぼ平坦な継承階層クラスは基本クラスから機能を継承します。これはカプセル化がほとんどないことを意味する。これは、ソリューションの中で非常に多くのクラスとして現れます。最後に、私が見たほとんどの場合、この方法でSpringを使用するアプリケーションでも、Springを使用するのではなく、包括的な設計が欠如しているため、パフォーマンス上の問題があります。 Springはフレームワークであり、アーキテクチャではありません。

Springが意味を持つ唯一の領域は、頻繁に変更される可能性が高いクラスまたは実行環境に結びついているクラス(テスト対生産)です。これらの領域以外にも、問題ドメインに存在するクラス間の関係(現実)もコード内に存在する必要があります。これらは変更されず、Spring Beanはパフォーマンスと開発成果物のオーバーヘッドを単純に追加します。

アプリケーションがうまく設計されていて、ほとんどの場合、おそらくそうでない場合、ライブラリまたはフレームワークは常に問題のドメインのクラスによってカプセル化されます。これは、具体的には、ライブラリまたはフレームワークがアプリケーションレベルで可視コンポーネントではないことを意味します。これは、どのようなOOA/OODの意味を持つ人にとっても明らかです。クラス間の関係を外部的に設定する能力を正式に含むビジネス・ワールドの単一の問題領域について考えることができます。はいと答えた場合、あなたはOOA/OODを理解できず、あなたはどこでもSpringを使用する人の1人になります。

Springを過度に使用しているのか誤って使用しているのかを知るためのリトマステストです。理論上、コードを変更することなくSpringを匹敵するものに交換できますか?もしそうでなければ、あなたは弱いデザインをしており、それを春と一緒に取り上げています。これは、アプリケーションのすべてのリリースで責任が増大する(ワークロードが増加する)場合に最もよく識別されます。

最後に、「Spring makes testing easy」という主張で、誰かがここにチャイムします。これはほとんどのケースで当てはまります。ほとんどのケースは設計が不適切なアプリケーションの一部です。 Springで構築されたアプリケーションよりもテストするのが簡単なのは、よく設計されたオブジェクト指向アーキテクチャー上に構築されたアプリケーションだけです。

関連する問題