私のチームは、Web フロントエンドを備えた新しいサービス指向の製品を開発しています。どのテクノロジーを使用するかについての議論では、JBoss アプリケーション サーバー、Flex フロントエンド (Adobe AIR を使用したデスクトップ展開も可能)、およびクライアントとサーバーをインターフェースする Web サービスを実行することに決めました。
ビジネス ロジックにどのサーバー テクノロジを使用するかについては、行き詰まりに陥っています。大きな議論は EJB3 と Spring の間であり、最大の関心事はスケーラビリティとパフォーマンス、そしてコード ベースの保守性です。
ここに私の質問があります：
パフォーマンスに基づいて、EJB3とSpringの間に大きな違いはありません。次の理由でSpringを選択しました（質問には記載されていません）。
明らかに、EJB3とSpringの間のギャップは以前よりもはるかに小さくなっています。とは言うものの、EJB3の欠点の1つは、Beanにしか注入できないため、コンポーネントを必要のないBeanに変換してしまう可能性があることです。
ユニットテストについての議論は今ではかなり無関係です-EJB3は明らかにユニットテストがより簡単になるように設計されています。
上記の互換性の議論も、一種の無関係です。EJB3またはSpringのどちらを使用する場合でも、サードパーティが提供するトランザクションマネージャーやJMSなどの実装に依存しています。
しかし、私にとってそれを揺るがすのは、コミュニティによるサポートです。昨年EJB3プロジェクトに取り組んでいたのですが、EJB3プロジェクトを使用して、問題について話している人はあまりいませんでした。春は、正しいか間違っているかにかかわらず、企業に特に浸透しており、解決しようとしているのと同じ問題を抱えている人を簡単に見つけることができます。
EJB3 対 Spring の賛成または反対の議論は何ですか? Spring は常に革新的であり、現実世界の制約を認識しています。Spring は、Java 1.4 アプリケーション サーバーにシンプルさと優雅さを提供し、2004 年から 2006 年には誰もアクセスできなかったバージョンの J2EE 仕様を必要としませんでした。 + 抽象化 + オープンソース対 Java Enterprise Edition (Java EE) 5.0 仕様。
Springは、Java EE 仕様と競合するだけでなく、補完するものだと思います。かつて Spring に固有であった機能が引き続き仕様に組み込まれるにつれて、EJB 3 はほとんどの内部ビジネス アプリケーションに対して「十分な」機能セットを提供すると多くの人が主張するでしょう。
それぞれにどのような落とし穴がありますか? これを永続性の問題（Spring + JPA）とEJB3として扱う場合、実際にはそれほど大きな選択をしていません。
良いベンチマーク情報はどこにありますか? しばらくの間、 specj ベンチマークの結果を 追っていませんでしたが、しばらくは人気がありました。各ベンダー (IBM、JBOSS、Oracle、および Sun) は、準拠したサーバーを持つことにますます関心を失っているようです。1.3、1.4 から進むにつれて、認定ベンダーのリストはどんどん短くなっていきます。1.5 Java エンタープライズ版。すべての仕様に完全に準拠した巨大なサーバーの時代は終わったと思います。
春よりもEJB3を絶対にお勧めします。より合理化され、コーディングがより適切になり、より適切にサポートされることがわかりました。私は過去にSpringを使用しましたが、非常に混乱し、EJB3（または1日の終わりに推測するJPA）ほど文書化されていないことがわかりました。
春は数週間しか試していなかったので、あまり話せません。しかし、全体的な印象は非常に悪かった。それが悪いフレームワークであることを意味するわけではありませんが、ここでの私たちのチームは、EJB3が永続性/ビジネスレイヤーに最適であることを発見しました。
私は EJB3 よりも Spring を好む傾向がありますが、どちらのアプローチを採用する場合でも、POJO の作成に固執し、可能な場合は標準のアノテーションを使用することをお勧めします。 @PostConstruct、@PreDestroy、@Resource などの JSR アノテーションは、EJB3 の両方で機能します。または Spring であるため、好みのフレームワークを選択できます。
たとえば、IoC の代わりに Guice を使用するプロジェクトを決定できます。
Web アプリケーションなどでリクエスト前の注入を使用したい場合、Spring よりも Guice の方が依存性注入がかなり高速であることに気付くかもしれません。
セッション Bean は、主に依存性注入とトランザクションに要約されます。そのため、EJB3 と Spring はその点で非常に似ています。Spring が優れているのは、より優れた依存性注入と、JMS などの優れた抽象化です。
私は過去に非常によく似たアーキテクチャを使用しました。Spring + Java 1.5 + Actionscript 2/3 を Flex Data Services と組み合わせると、コーディングが非常に簡単 (そして楽しい!) になりました。ただし、Flex フロント エンドは、十分に強力なクライアント マシンが必要であることを意味します。
あなたの質問について：
EJB3とSpringの賛否両論は何ですか？
専門家からの回答を読むことをお勧めします：回答：EJB3およびMarkFisherによる春の比較分析。コメントを読んで、Reza Rahmanの発言（EJB 3.0）を見つけてください。
Springを支持するもう1つの点は、Springとの統合をより適切にサポートしている他のツール/フレームワークのほとんどであり、それらのほとんどは内部でもSpringを使用します（たとえば、activemq、camel、CXFなど）。
また、EJB3よりも成熟しており、EJB3よりもはるかに多くのリソース（書籍、記事、ベストプラクティスなど）と経験豊富な開発者が利用できます。
EJB は優れたコンポーネント テクノロジですが、優れたフレームワークではないと思います。Spring は、現在利用可能な最高のフレームワークです。フレームワークの意味で、Spring を JEE の最良の実装と見なす必要があります。このプロジェクトにより、あらゆるコンポーネント テクノロジと簡単に統合できる柔軟性が得られます。