Tomcat アプリケーション サーバーと互換性があるように変更する必要がある EJB ベースのライブラリがあります (つまり、JaveEE はありません)。私は Hibernate を少しブラウジングしましたが、かなり混乱しました。
どうやら、Java SE準拠の.cfgファイルをベースとして使用する自然なHibernateブランチがあり、条件付きでJava EEに依存するJPAベースのHibernateブランチがあります。私が厄介だと思うことの 1 つは、一部のインターフェイスが明らかにサポートされていないことです。たとえば、CriteriaQuery です。
したがって、Java EE を取り除くという目標を達成するには、自然な Hibernate ブランチに移動する必要があると思います (違いを考えると面倒です)。OTOH、Tomcatに準拠したTomEEも利用可能であり、おそらくコードのほとんどを変更せずに保つことができます
感想をいただけると有難いです。ありがとう。
いくつかのポイント:
Java EE を嫌い、Java EE から離れたいという点では、それは本当に不可能な作業になります。これらのテクノロジーはすべて Java EE の一部です。
それらの一部を JavaEE とラベル付けし、一部を JavaEE とラベル付けすることは、一種の否定です。それらはすべて JavaEE の一部として作成およびリリースされています。
一部の反 JavaEE マーケティングが引き起こした混乱を解くことはほぼ不可能です。本当に有害なことは、3 つ以上の JavaEE テクノロジーを使用しない「非 JavaEE」アプリケーションを見つけることもほぼ不可能だということです。
「重い」問題と「多すぎる」問題に答えるために、2010 年に Web プロファイルが作成され、移植性を犠牲にすることなく、より小さなランタイムを作成できるようになりました。以下が含まれます。
分散トランザクションや重いものはありません。Tomcat、Hibernate、および Spring をスタックすると、以下が含まれます。
これらの API は、使用することを選択したかどうかに関係なく存在します。
実装自体を使用しても、標準 API を使用しないことにほとんど価値はありません。偽りの勝利です。同じランタイム コードを引き続き使用することになり、移植性がなくなります。
スプリングフレームワークまたは JavaEE は、現在、好みに応じて選択できるほど十分に近いものです (個人的には Java EE ですが、BMW とメルセデスのどちらが好みですか? :p)
つまり、JPA 仕様は最適なものではなく、javax.persistence パッケージの背後に隠れていても、hibernate/openjpa/eclipselink への特定の動作リンクを簡単に使用できます。
それは、一度学んだ Java 開発を大幅に軽減すると言われています
だから私のアドバイス：TomEEを使ってください。本当にブロックしているものが見つかった場合は、必要のないものを書き換えますが、IMOは時間を失うでしょう
TomEE については知りません。別の J2EE コンテナにデプロイしたいだけなら、コードを変更する必要はありません。
つまり、EE から離れたいということです。
「分散トランザクション」またはメッセージング サポート (IBM メインフレームとの間など) を持っている、または必要とする場合を除き、J2EE は大部分が失敗したアーキテクチャであるというのが私の意見です。
Tomcat、Spring、および Hibernate は、ほとんど単独で (JPA ラッパーまたは API を使用していません。これらは、Hibernate の最初の成功からコピーした余分なぼったくりレイヤーにすぎません) をお勧めします。
HB 構成のアノテーションを使用する場合は、コードで Hibernate API を使用しているときに、JPA のものを使用/組み合わせることができます (構文がより明確な場合もあります)。
乾杯、これが役立つことを願っています。