3

私たちはプロジェクトを開始しており、アーキテットは標準ですべてを使用したいと考えています (JodaTime の代わりにカレンダー - JPA2 対 Hibernate 4)。そして私は JPA2 を使用していましたが、「標準」と移植性の名目で非常に多くの機能が失われていることに気付きました。

そこで私は次の質問をします: 標準のためにいくつかの機能を失う価値はありますか? またその理由は何ですか?

移植性を考えるために ORM を変更するのは一般的ですか?

彼らは7年前のプロジェクトを持っていますが、まだOJBをORMとして使用しています...これについて教えてもらえますか?

ありがとう。

4

5 に答える 5

2

私の経験では、Hibernate4を使用します。アプリケーション内でORMフレームワークを変更することは決してありません。標準は、非標準と比較して非常に長いリリースサイクルを持っています。これにより、新機能やバグ修正を入手することが困難になります。さらに、Hibernateは準標準であると言えます。HibernateはJPAよりもはるかに多くの機能を提供します。私はそれらを束縛しません。

于 2012-06-21T02:51:29.303 に答える
1

標準ソリューションには、誰もが使用しているという利点があります。これの意味は：

  1. 技術に精通した人材を採用しやすくなり、人材育成も容易になる
  2. ライブラリが放棄されたり、使用に適さなくなったりする可能性は低くなります (たとえば、プロバイダーがベンダーロックインのために法外なライセンス料を支払うことができるため)。ライブラリは移行パスを開拓した可能性があります
  3. 必要が生じた場合に、標準の別の実装に切り替える方が簡単です (そして、おそらく何年にもわたってソフトウェアが維持されるので、その必要が生じないことを誰が確信できるでしょうか?)

たとえば、Red Hat が苦境に陥り、新しいバージョンの hibernate を自由に利用できるようにするのをやめたのに、今はライセンス料を要求している場合はどうなるでしょうか? または、Joda time のメーカーが開発を中止した場合はどうなりますか?

したがって、標準が存在する場合は標準を使用するのが理にかなっています。依存関係を制限するために開発の容易さをいくらか犠牲にすることも理にかなっています - どれだけの犠牲に値するかは、判断の呼び出しです (ライブラリをクラスパスにドラッグしても、実際の利益はありません。もう 1 つの極端な例は、車輪の再発明です)。 、単にホイールがまだ標準化されていないためです。)

彼らは7年前のプロジェクトを持っていますが、まだOJBをORMとして使用しています...これについて教えてもらえますか?

おそらく、コードが最新の実装がない API を使用して OJB と通信したため、プロバイダーを切り替えるのに非常に (法外に?) コストがかかりました。おそらく、それこそまさに、アーキテクトが標準 API に制限することで防ごうとしている状況です。

于 2012-06-21T07:07:03.860 に答える
0

JPA で解決することはおそらく良い考えです。必要なほとんどのことをカバーします。ただし、ORM の切り替えがいかに簡単であるかに基づいて決定を下すことはありません。それは決して起こらない可能性が高く、たとえ起こったとしても、最初に心配することがたくさんあります。

Hibernate を JPA プロバイダーとして使用している場合は、必要な場所でいつでも Hibernate 固有の機能にフォールバックできます。

于 2012-06-21T02:08:24.377 に答える
0

クイックワンライナー:

JPA - オブジェクト (JPA ではエンティティと呼ばれる) をデータベースに永続化/アクセス/更新するための Java 仕様 (Java EE の一部)。

Hibernate - JPA プロバイダー (つまり、オープンソース JPA 仕様実装の 1 つ)。また、JPA を使用せずに Hibernate を使用することもできます。

詳細については、こちらのブログをご覧ください。

于 2015-06-19T10:16:50.820 に答える
-2

Hibernate には、Hibernate-Search や Envers などの追加機能があります。

于 2012-10-03T03:25:00.447 に答える