新製品のリエンジニアリングのために、Java から最適なフレームワークを選択している最中です。モデルのデータベースに依存しないアプローチを検討しているため、iBATIS または Hibernate を使用した Struts + Spring の間のオプションに取り組んでいます。どちらも永続性を提供するため、どちらが最適かアドバイスをお願いします。
6 に答える
iBATIS と Hibernate はまったく別物です。
私がそれを見る傾向がある方法は次のとおりです。ビューがよりオブジェクト中心である場合、Hibernate はより適切に機能します。ただし、よりデータベース中心であると考える場合は、iBATIS がより強力な選択肢となります。
スキーマを完全に制御していて、極端に高いスループット要件がない場合、Hibernate は非常にうまく機能します。オブジェクト モデルは非常に便利なコードを作成しますが、複雑さが大幅に増大します。
かなり複雑な SQL クエリを記述する必要がある "レガシー" データベース スキーマを扱っている場合は、iBATIS がうまく機能する可能性があります。
HQL (Hibernate Query Language) は、習得しなければならないもう 1 つの言語であり、それでもSQL を記述する必要がある場合がおそらくあるでしょう。さらに、Hibernate にパフォーマンスの高い SQL クエリを生成させるために、XML、プロパティ、注釈などの適切な組み合わせを見つけるのに半日を費やす可能性もあります。
この質問に対する普遍的な「A は B よりも優れている」という答えはありません。
何を達成しようとしているのかを考えてみましょう。通常、コマンド クエリ応答分離 モデルは、複雑なドメインに適しています。
その理由は、通常、次の 2 つのいずれかを実行しようとしているからです。
- いくつかの複雑なドメイン エンティティの作成/更新/削除
- 分析フェッチ クエリ (つまり、合計/集計クエリ) を実行する
Hibernateはケース 1 でうまく機能し、POJO を作成して永続化/更新するだけで済みます。ドメインが非常に大きい場合を除き、これも迅速に行われます。
myBatisは、答えだけが必要なフェッチ クエリ (ケース 2) に最適です。Hibernate はオブジェクト グラフ全体をロードしようとするため、LazyLoading トリックを使用してクエリのチューニングを開始し、大規模なドメインで動作し続ける必要があります。逆に、分析 POJO ページだけが必要な場合は、同じクエリの myBatis 実装は簡単です。
このため、myBatisはSELECTSで Hibernate よりも高速です。
これら 2 つのケースは、ドメイン データを変更するコマンドと、データを取得するだけのレスポンスの違いです。
したがって、これら 2 つのケースと、アプリケーションが何をするかを考えてみてください。シンプルなドメインで情報を取得するだけの場合は、myBatis を使用してください。複雑なドメインがあり、エンティティを永続化する場合は、Hibernate を使用してください。両方を行う場合は、ハイブリッド アプローチを検討してください。これは、何千ものエンティティを制御下に置くプロジェクトで使用するものです。;)
ORM と永続化フレームワーク
Hibernate は、Java クラスをデータベース テーブルにマップするオブジェクト リレーション マッピング フレームワーク (ORM) です。MyBatis は永続化フレームワークであり、ORM ではありません。SQL ステートメントを Java メソッドにマップします。
データベース スキーマ
MyBatis にはそのような機能がありませんが、Hibernate は Java モデルに従ってデータベース スキーマを作成または検証できます。また、インメモリDBを利用する際のテスト環境としても便利です。関連する議論:
キャッシュ
Hibernate には無効にできない一次キャッシュがあります。これは、ORM を介して項目をクエリし、SQL を使用して直接削除すると、キャッシュに残ることを意味します。キャッシュを明示的にクリアして、データベースから最新の結果を取得できます。関連する議論:
楽観的なロック管理
また、楽観的ロック管理にも違いがあります。
MyBatis は、@Version アノテーションを使用した Hibernate/JPA などの ORM ツールとは異なり、楽観的同時実行制御をネイティブでサポートしていません。
関連する議論:
遅延読み込み
Hibernate は、遅延ロード用にマークされたオブジェクトを除いて、オブジェクト グラフ全体をロードしようとします。myBatis は SQL クエリに従ってデータを読み込みます。遅延読み込みはパフォーマンスを向上させる可能性がありますが、
<property name="hibernate.enable_lazy_load_no_trans" value="true" />
プロパティで使用すると接続リークが発生する可能性があります。関連する議論:
- org.hibernate.LazyInitializationException - プロキシを初期化できませんでした - セッションがありません
- hibernate.enable_lazy_load_no_trans で Hibernate Lazy-Init の問題を解決する
休止状態のセッション管理
保存、更新、削除などのエンティティ操作は、 Hibernate Sessionを介して実行されます。detached entity passed to persist
適切な Hibernate セッション管理戦略を実装して、Hibernate に関連するその他の現象を回避する方法を十分に理解する必要があります。
場合によっては、Hibernate の基本的な動作を理解しようとするほうが、もう少し作業を追加して myBatis 用の生の SQL ステートメントを記述するよりも時間がかかる場合があります。
カスケード
Hibernate はオブジェクト グラフにカスケード、オーファン削除、およびその他の機能を提供しますが、それらは myBatis にはありません。それらを実装するには、SQL クエリを明示的に記述する必要があります。
クエリ
myBatis では、ほぼプレーンな SQL クエリを記述します。Hibernate には、クエリを形成するための複数のオプションがあります: SQL、HQL、Criteria API。条件に多くのオプション フィールドがある場合、Criteria API を使用するのが適切な場合があります。クエリを形成するためのより構造化されたアプローチを提供し、関連する間違いを回避する可能性があります。
Cletus は、この比較を要約するのに優れた仕事をしました。Hibernate はデータ モデルを制御する場合にうまく機能し、よりオブジェクト中心であり、iBATIS は既存のデータベースと統合する必要があり、よりデータ中心である場合にうまく機能します。
また、Hibernate には学習曲線がもう少しあると思います。iBATIS を使用すると、Hibernate でより多くの「魔法」が発生する一方で、何が起こっているかを簡単に知ることができます。つまり、初心者は iBatis の方が使いやすく、理解しやすいと感じるかもしれません。
しかし、私は iBatis を好むべきだと言っているわけではありません。iBatis と Hibernate は上記のようにまったく異なります。
ところで、Hibernate を使用する場合は、標準化された JPA および EJB 3.0 (JSR-220) オブジェクト/リレーショナル マッピング アノテーションをHibernate Annotationsで提供することを検討してください。
すでに Spring を使用している場合は、Hibernate や iBatis に飛び込むのではなく、Spring JDBC から始めます。永続層をインターフェイスの観点から記述した場合、Hibernate または iBatis を習得した後は、問題なく実装を切り替えることができます。
「すべてかゼロか」の決定でなければならない理由はありません。状況に最適なものを使用してください。