EJB 3.1またはSpring 3 ..どちらを選択するか
EJBは3.xバージョンで多くの改善を達成しました。Springも一般的に使用されており、バージョン3は優れた代替手段です。
Webには多くの記事がありますが、ejb3xとspring3xについての正確な比較はありません。実際の例では、どの条件でどれが優れているかについてのアイデアはありますか？
たとえば、dbとserverを分離したい、つまりアプリケーションがサーバー上にあり、データベースが別のサーバー内にあることを意味します。EJBremoting vs Cluster4Springなど？
@Annotationを毎回実行することは常に良いですか？構成は必要ありませんか？
アプリケーションが1つのサーバーで実行され、データベースが別のサーバーで実行されるユースケースでは、EJBとSpringの選択は無関係です。 Java SEアプリケーション、TomcatやJettyのようなシンプルなサーブレットコンテナ、PHP、Ruby on Rails、その他何でも。
そのための明示的なリモート処理は必要ありません。データソースを定義するだけで、DBサーバーが存在するURLを指定するだけです。
ただし、EJBとSpring Beanの両方により、データソースの操作が容易になります。これらは両方とも、データソースの定義、Beanへの注入、およびそれらに関連付けられたトランザクションの管理に役立ちます。
2つのうち、EJB（およびJava EE一般）はより軽量であり、構成原則よりも慣習に準拠しています。Springは同じことを得るためにより多くの冗長性を必要とし、XMLファイルに大きく依存します。コインの裏側は、Springの魔法の度合いが低くなる可能性があり、必要なすべてのスペルを入力した後、よりコントロールしやすくなる可能性があるということです。
もう1つの問題は、EJBとSpringの開発方法です。
EJBは無料（無料のビールのように）、オープンソースであり、非独占的です。非営利組織（Apache）、オープンソース企業（Redhat/JBoss）、および非常に商業的なクローズドソース企業（IBM）によって作成されているEJBの実装があります。私は個人的には後者を避けますが、それぞれに彼自身のものです。
一方、Springは無料でオープンソースですが、独自の製品です。 Springを作成している会社は1社のみであり、それがSpringsourceです。あなたがロッドに同意しない場合、あなたのための厳しい運。これは必ずしも悪いことではありませんが、注意すべき違いがあります。
@Annotationを毎回実行することは常に良いですか？構成は必要ありませんか？
それは本当に終わりのない議論です。 XMLの保守が難しいと主張する人もいれば、注釈が本来のPOJOモデルを汚染すると主張する人もいます。
EJBステートレスBean（@Stateless）またはJPAエンティティ（@Entity）としてBeanに注釈を付けることは、注釈を使用してよりきれいに行われると思います。 @EJBまたは@Inject依存性注入についても同様です。一方、JPQLの名前付きクエリは、アノテーションではなくXMLファイルに入れ、純粋な構成データ（何かの最大値など）を表すインジェクションもXMLに入れることを好みます。
Java EE、すべての注釈はXMLでも指定できます。注釈とそれに相当するXMLの両方が存在する場合、XMLは注釈を無効にします。これにより、デフォルトのケースですが、特定のユースケースのためにXMLを介して後でオーバーライドします。
Java EEの現在の設定は、設定よりも多くの慣習と組み合わされた（単純な）注釈に向かっているようです。
あなたが尋ねるべき本当の質問はCDI/EJBまたはSpringです
多くの場合、Spring vs EJBではありませんが、Spring vs JavaEE。EJB自体はSpring Beanと比較されます。どちらも、コンテナ（EJBコンテナまたはSpringコンテナ） ）。
全体的に、2つのテクノロジーはかなり似ています。 Reza Rahmanは、しばらく前からこの2つを大いに比較しました。
EJBは標準化されているため、より有利です。軽量のアプリケーションを使用している場合、Springを使用するのは問題ないと思いますが、アプリケーションが大きくなり、大量のメモリアクセスとデータ接続アクセスが必要になると予想される場合は、EJBで開発を開始することを検討してください。クラスタリングと負荷分散が主な理由は、EJBフレームワークに組み込まれています。
EJB環境では、EAR（ 'E'nterprise' AR'chive）がデプロイされると、それぞれが特定の目的を持つ複数のEJB Beanとともにデプロイされる場合があります。ユーザー管理用のBeanと製品管理用の別のBeanを作成したとしましょう。ある日、ユーザーサービスの方法が製品アクセスサービスを超えており、ユーザーBeanを別のマシンの別のサーバーに移動したいと思うかもしれません。これは、コードを変更せずに実際に実行時に実行できます。 Beanはサーバーとデータベース間で移動でき、開発者やユーザーに影響を与えることなくクラスタリングとロード/データバランシングに対応できます。そのほとんどはデプロイメントレベルで構成できるためです。
標準をサポートするもう1つの理由は、ほとんどの大規模なサードパーティベンダーが標準をサポートし、新しい標準/サービス/テクノロジと統合する際の問題が少なくなることを知っていることです。そして、それが公開仕様であれば、新しい新興企業や親切な開発者がオープンソース版を作成できます。
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
最も知的なデザイナーやプログラマーでさえ、どの機能が開発コミュニティに受け入れられるかどうかを予測できないことは最も残念なことです。これがソフトウェアが肥大化する主な理由です... Java EE間違いなくそれです！
両方ではなく、どちらかを選択してください。
私の個人的な好みは春です。私は過去6年間、大きな成功を収めたプロジェクトに使用しました。他のソフトウェアと同様に堅実です。
アプリケーションでEJBを使用することを選択した場合、SpringはEJBを使用できますが、その逆は当てはまりません。
余裕があれば、Webサーバー、アプリサーバー、およびデータベースサーバーに個別の物理マシンを使用することをお勧めします。
Springは、SOAPおよびREST Webサービス。SpringBeanとEJBの比較はこの質問の範囲外です。実装で何が関係しているかわからない。SpringPOJOサービスを使用する場合、リモートEJBのような別のネットワークホップを必要とするのではなく、インメモリである。正当な理由による待ち時間。
ここでユニットテストについて言及します。一般的なWebアプリケーション（controller-> service-> data-> ...-> view）では、EJBとSpringはどちらも同様の結果を提供しますが、springはより簡単なテストを提供します。
私の謙虚な経験では、あなたの開発方法はいくつかの面で異なります。
- 単体テスト（春の勝利）。春には、かなり順調に行われますが、ejbでは、すべてのビルドで実行が遅いShrinkWrap（sic！）でArqullianを使用する必要があります。
- 永続性（ejbが勝ちます）。春には、それをめぐって闘争があります。つまり、「エンティティリスナで永続性を自動配線する方法」Google http://bit.ly/1P6u5WO
- 構成（ejbが優先）。 ejbから春に来る初心者として、アノテーションと.xmlファイルの群れに驚いた。
EJB 3.1は、Java 6 EEアプリケーションの標準でありながら最適です。
SpringはまだサポートしていませんJava 6 CDI（weld）もXML構成に大きく依存しています。EJB3.1は強力でスマートです。
Spring 3.1はXML構成を必要としないと思います。構成に注釈を使用するオプションがあります。