なぜSpringフレームワークではないのですか？
アプリケーションをSpringフレームワークに結び付けることに不利な点はありますか？
私はそのようなバグや問題について話しているのではありません。私は、アプリケーションのライフサイクルに影響を与える、戦略的でアーキテクチャ上のことについて話しています。
Java EEコンテナがサポートするEEコア機能よりもSpringを優先すべきですか？利点は何ですか？
ここの他の投稿では上向きに言及しているので、Springの否定的な側面について言及します。これらの不利な点があっても、Springはニッチで遍在し、信頼性が高く、宣伝どおりに機能します。
それで、ネガについて：
巨大：3000クラスのjarファイルを小さな趣味のプロジェクトに入れたくありません。
GuiceやPicoのような他のいくつかのDIフレームワークよりも遅いといういくつかの説明があります。逸話的で、おそらくあまり重要ではありません。
コアの一部が十分に文書化されていない場合や、複数のメジャーバージョン間で相違していることが判明した場合は、Springの一部を処理することでイライラすることがあります。
そのサイズの副次的な影響として、論理的に名前が付けられている間、疲れたときに一緒に巨大な名詞の山にマージし始めるクラスの山を掘り起こす楽しい時間を過ごす準備をしてください（「確かに、単にTransactionAwareConnectionFactoryProxyをUserCredentialsConnectionFactoryAdapterを.. zzzzzzzz "）に追加します。公正を期すために、これらは実際には論理的に名前が付けられていますが、フレームワークのサイズに対する妥当な対応ですが、それでも変わりません。
おそらく、新しい作品のこの適応の結果として、少なくとも私にとって春は遅くなる可能性があります。コアスプリングについてはそれほどではありませんが、ほぼすべてのコネクタがあります。また、すべてが十分に文書化されているわけではありません。名詞のスープを調べ始めるときです。繰り返しますが、それは実際にはすべてそのサイズに応じたものです。
Springの欠点はほとんどありません
Springを使用することの重大な欠点を見つけるために、長くて難しいと思いましたが、失敗したと思います。 Springは、JEE/OSGiモデル内の優れたツールキットです。アプリケーションコンテナによって提供される、しばしば煩わしいサポートAPIでの作業を大幅に簡素化する、幅広い非侵襲的なテンプレートを提供します。
スプリングvsコアJEE
SpringはコアJEEテクノロジー（おそらくEJB）に取って代わるものではありませんが、新しいEJB3仕様にはほとんど何もありません。 JAX-RSがRESTful WebサービスAPIであると考えてください。 SpringはRestTemplateを提供します。これは通常、次のように使用されます（注入されていると想定しています）。
SomeJaxbAnnotatedClass object = restTemplate.getForObject(someURI,SomeJaxbAnnotatedClass.class);
これはsomeURIに進み、XML/JSON/YAMLを取得して、指定したドメインオブジェクトに非整列化します。すべて1行のコードで。
例外とエラーロギングはランタイム例外として処理されるため、ローカルコードをきれいに保つことが容易になります。 Springは、可能な場合は常に外部依存関係を減らすように機能するため、上記の例ではJava.net。*パッケージのみを使用しています。
JMS、JAX-WS、JPA、JTAなどのテンプレートがあります。これらすべてにより、これらの標準での作業がmuch簡単になり、コードがよりクリーンになり、エラーが発生しにくくなります。
Pick'n'mixアーキテクチャ
アーキテクチャーの観点から見ると、Springは軽量のピック・アンド・ミックス・アプローチを強調しています。これにより、システムアーキテクトは、WebSphere、JBoss、Glassfishなどのすべての人のための肥大化したアプリケーションコンテナーの使用を回避し、代わりに軽量版（Jetty、Tomcatなど）を選択できるようになります。
何でこれが大切ですか？大規模なアプリケーションコンテナーは、更新サイクルがはるかに長く、一部のクライアントのニーズに他のクライアントよりも適しています。銀行は、一人のスタートアップほど俊敏である必要はありません。
サポートするフレームワークの最新バージョンを利用したい場合は、大規模なアプリケーションコンテナーでそれらを見つけることはほとんどありません。代わりに、それらを手動で含める必要があり、Springを使用すると簡単です。
また、必要なテクノロジーを具体的に含めるだけで済みます。アプリケーションコンテナは、JMS、EJB、およびSunの下の他のすべての頭字語を提供しますが、JPAで簡単に永続化したいだけです。 SpringとHibernateを含めれば完了です。
それでなぜ春ではないのですか？
ライブラリのベンダー固有の実装を使用する場合は、Springを避けてください。また、構成の詳細をXMLまたはJNDIに外部化するのではなく、クラス内に保持したい場合も避けてください。また、無料のオープンソースソリューションが環境に適していないと思われる場合は、絶対に避けてください。
martin Thompsonが この記事 で言及している興味深い点の1つは、春がGC時間に重要な影響を与える可能性があることです。
呼び出しスタックを適度に小さくしてください。ここでやるべきことはまだまだあります。 Springを使用するのに十分夢中になっている場合は、コールスタックをチェックして、私の意味を確認してください！ガベージコレクターは、到達可能なオブジェクトを見つけるためにそれらを歩く必要があります。 -マーティン・トンプソン
この種のことはほとんどの種類のアプリにとって大きな問題にはなりませんが、マーティンが言及している種類のアプリにとっては非常に現実的な懸念事項です。
春は本当にいいです。 Spring Coreは問題ありません。他の点についても付け加えておきますが、パフォーマンスが本当に懸念されるニッチカテゴリに属している場合は、トップの開発者の手元にある場合にのみ、他のSpringモジュールを避けたいでしょう。これは、パフォーマンスが本当に重要なシステムを実行している場合にのみ問題になります。平均的な優れた開発者にとって、Springはおそらく、クリーンでシンプルなコードの記述を支援することにより、おそらくパフォーマンスを向上させます。
Springは、アプリケーションコードとの疎結合を維持するという点で、非侵襲性になるように努力しています。
それはまた、tiemよりもその方向に動いています。以前のバージョンでは、基本クラスを拡張する必要があり、その後、アノテーションに移行しました。現在では、XMLで構成されたPOJOの使用が増えています。
これは、他のアプリケーションフレームワークに比べて大きな戦略的メリットです。
春は基本的に現在プラットフォームの一部となっています。 JEE5および6の至る所でリソースインジェクションがますます多く見つかるので、少なくともSpringのその部分は、それに固執した場合、プラットフォームの別の部分になります（@Injectを参照）。その他の部分...特にアスペクト指向プログラミングに関しては、よくわかりません。これらのサービスの他のプロバイダーがあり、Guice（元々はGoogleから）およびWeld（JBossから）は、Guiceに基づいて構築されており、JSR-330に依存している場合は同じ機能を提供しますJava依存関係噴射仕様。
YMMV