ビジネス層には EJB3 または Spring を使用する必要がありますか?

https://stackoverflow.com/questions/68527

09-06-2019
|

質問

私のチームは、Web フロントエンドを備えた新しいサービス指向製品を開発しています。どのようなテクノロジーを使用するかについての議論の中で、JBoss アプリケーションサーバー、Flex フロントエンド (Adobe AIR を使用したデスクトップ展開も可能)、およびクライアントとサーバーを接続するための Web サービスを実行することに落ち着きました。

ビジネスロジックにどのサーバーテクノロジを使用するかという点で行き詰まりました。大きな議論は EJB3 と Spring の間であり、私たちの最大の懸念はスケーラビリティとパフォーマンス、そしてコードベースの保守性です。

私の質問は次のとおりです。

EJB3 と Spring に対して賛成または反対の議論は何ですか?
- それぞれにどのような落とし穴が予想されますか?
- 適切なベンチマーク情報はどこで入手できますか?

解決

パフォーマンスに基づくと、EJB3 と Spring の間に大きな違いはありません。次の理由から Spring を選択しました (質問には記載されていません)。

Spring は、単体テストをより容易にサポートする方向にアーキテクチャを推進します。たとえば、モック DAO オブジェクトを挿入してビジネス層の単体テストを行ったり、Spring の MockHttpRequest オブジェクトを利用してサーブレットの単体テストを行ったりします。単体テスト用に別の Spring 構成を維持し、テストを特定のレイヤーに分離できるようにします。
最も重要な要因は互換性でした。複数のアプリケーションサーバーをサポートする必要がある場合 (または、最終的に 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 仕様という、まるで宗教的な議論に巻き込まれる可能性があります。

春だと思います 競合するというよりも補完する Java EE仕様に準拠しています。かつて Spring に固有だった機能が仕様に組み込まれ続けているため、多くの人は、EJB 3 がほとんどの社内ビジネスアプリケーションに「十分な」機能セットを提供していると主張するでしょう。

それぞれにどのような落とし穴が予想されますか?これを永続性の問題 (Spring+JPA) と EJB3 として扱う場合は、実際にはそれほど大きな選択をする必要はありません。

適切なベンチマーク情報はどこで入手できますか?フォローしていません specjベンチマーク結果しばらくの間は人気がありましたが。各ベンダー (IBM、JBOSS、Oracle、Sun) は、準拠サーバーを持つことにますます関心がなくなっているようです。1.3、1.4 に進むにつれて、認定ベンダーのリストは短くなっていきます。1.5 Java エンタープライズエディション。すべての仕様に完全に準拠した巨大なサーバーの時代は終わったと思います。

春には間違いなく EJB3 をお勧めします。これは、より合理化され、コーディングしやすく、サポートも充実していることがわかりました。私は過去に Spring を使用したことがありますが、非常にわかりにくく、EJB3 (結局のところ JPA だと思います) ほど文書化されていないことがわかりました。

EJB3 では、外部構成ファイルを扱う必要がなくなり、データベーステーブルごとに注釈を付ける POJO は 1 つだけになります。この POJO は問題なく Web 層に渡すことができます。Netbeans などの IDE は、これらの POJO を自動生成することもできます。私たちは現在、かなりの数の大規模アプリケーションのバックエンドとして EJB3 を使用していますが、パフォーマンスの問題には気づいていません。セッション Bean は、Flex フロントエンドに公開できる Web サービスとして簡単に公開できます。セッション Bean は、必要に応じてメソッドまたはクラスレベルで簡単にロックダウンしてロールなどを割り当てることができます。

数週間試しただけなので、春についてはあまり語れません。しかし、全体的な印象は非常に悪かったです。それは悪いフレームワークであるという意味ではありませんが、私たちのチームは EJB3 が永続化/ビジネス層に最適であることを発見しました。

私は EJB3 よりも Spring を好む傾向がありますが、どちらのアプローチを取る場合でも、POJO の作成にこだわり、EJB3 の両方で動作する @PostConstruct、@PreDestroy、@Resource などの JSR アノテーションなど、可能な限り標準アノテーションを使用することをお勧めします。または Spring なので、お好みのフレームワークを選択できます。

例えばIoC の代わりに Guice を使用するプロジェクトを決定することもできます。

Web アプリケーションなどでリクエスト前注入を使用したい場合は、Guice の依存関係注入が Spring よりもかなり高速であることに気づくかもしれません。

セッション Bean のほとんどは、依存関係の注入とトランザクションに要約されます。その点では、EJB3 と Spring は似ています。Spring が優れているのは、より優れた依存性注入と、JMS などのより優れた抽象化です。

私は過去に非常によく似たアーキテクチャを使用したことがあります。Spring + Java 1.5 + Actionscript 2/3 を Flex Data Services と組み合わせると、コーディングが非常に簡単 (そして楽しい!) になりました。ただし、Flex フロントエンドを使用するには、十分に強力なクライアントマシンが必要です。

あなたの質問に関して：

EJB3 と Spring に対して賛成または反対の議論は何ですか?

専門家からの回答を読むことをお勧めします。以下への返答:Mark Fisher による EJB 3 とスプリングの比較分析. 。コメントを読んで、Reza Rahman の発言 (EJB 3.0) を見つけてください。

Spring を支持するもう 1 つの点は、世に出ている他のツール/フレームワークのほとんどが Spring との統合をより適切にサポートしており、そのほとんどが内部でも Spring を使用していることです (例:activemq、キャメル、CXF など)。

また、EJB3 よりも成熟しており、EJB3 よりも多くのリソース (書籍、記事、ベストプラクティスなど) と経験豊富な開発者が利用できます。

EJB は優れたコンポーネントテクノロジだと思いますが、優れたフレームワークではありません。Spring は現時点で利用可能な最高のフレームワークです。したがって、フレームワークという意味では Spring が JEE の最良の実装であると考える必要があり、私の推奨事項は、あらゆる場合に Spring を使用することです。このプロジェクトにより、あらゆるコンポーネントテクノロジと簡単に統合できる柔軟性が得られます。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow