ビジネスレイヤーにEJB3またはSpringを使用する必要がありますか？
私のチームは、Webフロントエンドを備えた新しいサービス指向の製品を開発しています。どのテクノロジーを使用するかについての議論では、JBossアプリケーションサーバー、Flexフロントエンド（Adobe AIRを使用したデスクトップ展開が可能）、およびクライアントとサーバーをインターフェースするWebサービスの実行について説明しました。
ビジネスロジックに使用するサーバーテクノロジーに関しては、行き詰まりました。大きな議論はEJB3とSpringの間であり、最大の関心事はスケーラビリティとパフォーマンスであり、コードベースの保守性でもあります。
私の質問は次のとおりです。
- EJB3対Springの賛否両論は何ですか？
- それぞれにどんな落とし穴がありますか？
- 優れたベンチマーク情報はどこで入手できますか？
EJB3とSpringのパフォーマンスに基づく違いはあまりありません。 Springを選択した理由は次のとおりです（質問には記載されていません）。
- Springは、単体テストをより簡単にサポートできる方向にアーキテクチャを駆動します。たとえば、モックDAOオブジェクトを挿入してビジネスレイヤーを単体テストするか、SpringのMockHttpRequestオブジェクトを使用してサーブレットを単体テストします。ユニットテスト用に個別のSpring構成を維持し、テストを特定のレイヤーに分離できるようにします。
- 優先ドライバーは互換性でした。複数のApp Serverをサポートする必要がある場合（または最終的にJBossからGlassfishなどに移動するオプションが必要な場合）、異なる実装間の互換性に依存するのではなく、本質的にコンテナ（Spring）を持ち歩くことになりますEJB3仕様。
- Springでは、永続性、オブジェクトのリモート処理などのテクノロジーを選択できます。たとえば、Flexフロントエンドも使用しており、FlexとSpring間の通信にヘッセプロトコルを使用しています。
EJB3とSpringのギャップは、明らかに以前よりもずっと小さくなっています。ただし、EJB3の欠点の1つは、Beanにしか注入できないことです。そのため、コンポーネントを必要のないBeanに変えることができます。
単体テストに関する議論は今ではかなり無関係です-EJB3はより簡単に単体テスト可能になるように明確に設計されています。
上記の互換性の引数も、無関係です。EJB3を使用するか、Springを使用するかに関係なく、サードパーティが提供するトランザクションマネージャー、JMSなどの実装に依存しています。
しかし、私にとってそれを揺るがすのは、コミュニティによるサポートです。昨年、EJB3プロジェクトに取り組んでいたとき、それを使用して問題について話している人はあまりいませんでした。正しいか間違っているかにかかわらず、Springは非常に広範であり、企業に特化しています。これにより、解決しようとしている同じ問題を抱えている人を簡単に見つけることができます。
EJB3対Springの賛否両論は何ですか？Springは常に革新的であり、現実の制約を認識しています。 SpringはJava 1.4アプリケーションサーバーのシンプルさと優雅さを提供し、2004年から2006年に誰もアクセスできなかったバージョンのJ2EE仕様を必要としませんでした。吸い込まれる可能性についての議論-Spring +抽象化+オープンソース対Java Enterprise Edition（Java EE）5.0仕様。
Springは、Java EE仕様と競合する以上のものを補完していると思います。 、EJB 3はほとんどの内部ビジネスアプリケーションに「十分な」機能セットを提供すると多くの人が主張します。
それぞれにどのような落とし穴がありますか？これを永続性の問題（Spring + JPA）対EJB3として扱うのであれば、それほど大きな選択をしません。
どこで良いベンチマーク情報を見つけることができますか？しばらくの間 specjベンチマーク結果 に従っていませんでしたが、しばらく人気がありました。各ベンダー（IBM、JBOSS、Oracle、およびSun）は、準拠サーバーを使用することにますます関心を持たなくなっているようです。 1.3、1.4から進むにつれて、リストは認定されたベンダーが短くなります。 1.5 Java Enterprise Edition。すべての仕様に完全に準拠している巨大なサーバーの時代は終わったと思う。
私は間違いなく春よりもEJB3をお勧めします。私たちは、より合理化されており、コードを作成するのに適していて、より適切にサポートされていることがわかります。私は過去にSpringを使用しましたが、非常に紛らわしいことがわかりましたが、EJB3（または私が推測するとJPA）ほどよく文書化されていません
- EJB3の時点で、外部設定ファイルを扱う必要はなくなり、データベーステーブルごとに注釈を付けるPOJOは1つだけになりました。このPOJOは、問題なくWeb層に渡すことができます。 NetbeansなどのIDEは、これらのPOJOを自動生成することもできます。かなりの数の大規模アプリケーションのバックエンドとしてEJB3を使用しましたが、パフォーマンスの問題に気づいていません。セッションBeanは、Flexフロントエンドに公開できるWebサービスとして簡単に公開できます。セッションBeanは、メソッドまたはクラスレベルで簡単にロックダウンして、必要に応じてロールなどを割り当てることができます。
数週間しか試していないので、春についてはあまり話せません。しかし、私の全体的な印象は非常に悪かったです。それが悪いフレームワークであることを意味するわけではありませんが、私たちのチームはEJB3が永続性/ビジネスレイヤーに最適であることを発見しました。
私はEJB3よりもSpringを好む傾向がありますが、私の推奨事項はどちらのアプローチでもあり、POJOの作成に固執し、可能な限り標準のアノテーションを使用してみてください。またはSpringを使用すると、好みのフレームワークを選択できます。
例えばIoCの代わりにGuiceを使用するプロジェクトを決定できます。
Webアプリケーションなどで事前リクエストインジェクションを使用する場合、GuiceはSpringよりも依存性インジェクションの方がかなり高速であることがわかります。
セッションBeanは、主に依存関係の注入とトランザクションに要約されます。そのため、EJB3とSpringは本当に似ています。 SpringにEdgeがあるのは、JMSのようなものに対するより良い依存性注入とより良い抽象化です
過去に非常によく似たアーキテクチャを使用しました。 Spring + Java 1.5 + Actionscript 2/3とFlex Data Servicesを組み合わせることで、非常に簡単に（そして楽しい！）コーディングできました。 。
あなたの質問について：
EJB3対Springの賛否両論は何ですか？
専門家からの回答を読むことをお勧めします： 回答：Mark Fisher によるEJB 3と春の比較分析。コメントを読んで、Reza Rahmanの発言（EJB 3.0）を見つけてください。
もう1つのスプリングの利点は、他のツール/フレームワークのほとんどが、スプリングとの統合をよりよくサポートしていることです。それらのほとんどは、内部でスプリングも使用しています（例：activemq、ラクダ、CXFなど）。
また、より成熟しており、EJB3よりも多くのリソース（書籍、記事、ベストプラクティスなど）と経験豊富な開発者が利用できます。