Spring対EJB。SpringはEJBを置き換えることができますか?[閉まっている]


96

以来春は同じようにトランザクションを使用することができますEJB。私にとって、SpringはEJBを使用する要件を置き換えることができます。EJBを使用することのその他の利点は何ですか?

回答:


201

Springは当初からEJBの代替として開発されたので、答えはもちろんEJBの代わりにSpringを使用することです。

EJBを使用する「利点」がある場合、チームのスキルに依存すると思います。Springの専門知識がなく、EJBの経験が豊富な場合は、EJB 3.0を使用することをお勧めします。

EJB標準をサポートするように作成されたアプリサーバーは、理論的には、1つの準拠Java EEアプリサーバーから別のアプリサーバーに移植できます。しかし、それは、1つのベンダーに縛られるベンダー固有の拡張機能から離れることを意味します。

アプリサーバー(WebLogic、Tomcat、JBOSSなど)に依存しないため、それらの間で簡単にSpringポート。

しかし、あなたは春に閉じ込められています。

Springは、Guiceや別のDIフレームワークに切り替えることを決定した場合でも、影響のある問題に利益をもたらす優れたOO設計プラクティス(インターフェース、レイヤー、懸念の分離など)を奨励します。

更新:この質問と回答は2014年に5年目です。プログラミングとアプリケーション開発の世界は、その時代に大きく変化したと言われる必要があります。

それはもはや、JavaかC#、SpringかEJBの間の単なる選択ではありません。vert.xそれは全くのJava EEを避けることが可能です。アプリサーバーがなくても、拡張性の高いポリグロットアプリケーションを作成できます。

更新:2016年3月です。Spring Bootは、Java EEアプリサーバーなしでアプリケーションを作成するさらに優れた方法を提供します。実行可能JARを作成して、JVMで実行できます。

OracleがJava EE仕様を引き続きサポートするかどうか疑問に思います。EJBはWebサービスに引き継がれました。EJBソリューションは機能していません。(ちょうど私の意見です。)


7
私の意見では、「ロックイン」は春を表すには強すぎるフレーズです。結局のところ、Springはすべてを接着するように設計されており、それらを置き換えるのではなく、いつでも統合したいものを選択できます。その上、すべてがロックインされており、最も単純なApache Commonsでさえロックインされていますが、それでも毎日使用しています。
クリストファーヤン

3
VMWare / Springに代わるベンダーはなく、Java EEプラットフォーム用にOracle、Red Hat、IBMから選択できます。私が言ったのはそれだけです。Springの機能や有用性についてのコメントではありません。たまに気に入ってます。毎日使って夜寝ます。
duffymo 2013

1
@ChristopherYang正解です。つまり、「Java」はベンダーロックンです。したがって、最終的には、議論をやめて何かを行う必要があるだけです。:-)
cbmeeks

4
この質問はほぼ5年前のものです。個人的には、EJBはHTTP Webサービスにあらゆる方法で負けてきた時代遅れのテクノロジーだと思います。シンプルでオープンな勝利。RESTサービスを提供してください。EJBを保持できます。春はそれらをうまくサポートします。それが世界が去ったところです。
duffymo 2014年

1
返信いただきありがとうございます。既存のEJB 2.1アプリケーションからの移行に適したもの(SPRING、EJB 3.x)を評価する際の利点を探すだけです。もう1つの質問、EJB 3.xはWebServiceもサポートしています。では、Javaアプリの配布にはJNDI / RMIを、他のアプリにはWSを利用できるでしょうか。
noboundaries 2014年

48

まず、はっきり言っておきますが、Springを使用するべきではないと言っているのではありません。

  • EJB 3は標準ですが、Springはそうではありません(事実上の標準ですが、同じことではありません)。これは当面は変更されません。Springフレームワークは任意のアプリケーションサーバーで使用できますが、Springアプリケーションは、Spring自体と、Springに統合するために選択した特定のサービスの両方にロックされます。

  • Springフレームワークは、アプリケーションサーバーとサービスライブラリの上に配置されます。サービス統合コード(データアクセステンプレートなど)はフレームワークに常駐し、アプリケーション開発者に公開されます。対照的に、EJB 3フレームワークはアプリケーションサーバーに統合され、サービス統合コードはインターフェースの背後にカプセル化されます。したがって、EJB 3ベンダーは、アプリケーションサーバーレベルで作業することにより、パフォーマンスと開発者エクスペリエンスを最適化できます。たとえば、JPAエンジンをJTAトランザクション管理に密接に結び付けることができます。別の例は、EJB 3開発者に透過的なクラスタリングサポートです。

ただし、EJB 3は完全ではありませんが、いくつかの機能が不足しています(たとえば、単純なPOJOなどの非管理対象コンポーネントのインジェクション)。


1
教育的な答えですが、なぜ/いつ新しいPOJOを初期化する代わりに単純なPOJOを注入する必要があるのでしょうか。
オメルファルクAlmalı

4
テスト目的。
フィリップ

22

パスカルのポイントは有効です。ただし、春を支持して次のようなものがあります。

  • EJB仕様は実際には少し緩いため、さまざまな動作がさまざまなアプリケーションサーバーで確認できます。もちろん、これはほとんどの場合には当てはまりませんが、一部の「暗いコーナー」ではそのような問題がありました。

  • Springには、spring-test、AOP、MVC、JSF統合などの追加機能がたくさんあります。EJBにはそれらの一部(インターセプターなど)がありますが、私の意見では、それほど開発されていません。

結論として、それは主にあなたの正確なケースに依存します。


たぶんSpringのようなものはサーブレットエンジンだけが必要な方がより正確でしょう(EJBはあらゆるJEEコンテナ、サーブレットエンジンで使用できます!= JEEコンテナ)。
Pascal Thivent 2009年

1
まあ、技術的には、Springにはサーブレットエンジンも必要ありません。たとえば、spring-testはメモリ内コンテキストを使用します。
Bozho

3
まあ、技術的には、EJBはスタンドアロンコンテナーを必要としません。EJB 3.1以降EJBContainer.createEJBContainer()、埋め込みコンテナを使用するための標準APIがあります。したがって、それでも、あなたの発言は間違っています。
Pascal Thivent 2009年

わかりました。3.1はかなり新しく、明らかに追加を忘れていました。私の答えからその点を取り除いた。
Bozho

-30

SpringはEJBを補完するものであり、EJBを置き換えるものではありません。SpringはEJBの上にあるレイヤーです。ご存知のとおり、EJBのコーディングはAPIを使用して行われます。つまり、Springフレームワークを使用してAPIにすべてを実装する必要があります。ボイラープレートコードを作成し、そのプレートを取得し、それに何かを追加するだけで、すべてが完了します。内部的にSpringはEJBと接続されています-SpringはEJBなしには存在しません。

Springを使用する主な利点は、クラス間にまったく結合がないことです。


8
あなたは完全に間違っています。申し訳ありません
Jakub H 14

2
申し訳ありません@sasiこれは.......でも近い正しいか素敵な答えにではありません
Prakashの

4
「SpringはEJBなしには存在しませんでした。」男、あなたは本当ですか?これまでに、EJBの宣言で「\ @Stateless」を使用したり、\ @ EJBアノテーションを注入に使用したことはありますか?JettyやTomcatで動作すると思いますか?トランザクションは春に管理されていると思いますか?Springアプリケーションをサーブレットコンテナーにデプロイできることをご存知ですか?
99Sono 2015

申し訳ありませんが、EJBはJava EEの一部であり、Springは構成上の規約の原則として理解されています。実際には、深く掘り下げないと、それらがどれほど同じものであるか、関連しているのか、またはそのようなものであると考えてしまう可能性があります。どうして?どちらも注射のような類似点がありますが、両者の違いは非常に大きいです。確かに、EJBの複雑さのため、Springは過去のEJBの代替として生まれましたが、そうです。Time of Java EE 5(EJB 3)の間は、春がCOCで行っていたように修正されました
Ishimwe Aubain Consolateur
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.