Java 開発で使用する 2 つの主流フレームワークの組み合わせは、SSM、Spring、SpringMVC、MyBatis と SSH、Struts2、Spring、および Hibernate です。今日は、まず 2 つのデータベース フレームワークの違いを見ていきます。
第一の側面: 開発速度の比較
開発速度の点では、Mybatis よりも Hibernate を完全に使いこなすのは難しいいくつかの。 Mybatis フレームワークは比較的シンプルで使いやすいですが、比較的粗雑でもあります。個人的には、Mybatis を使いこなすには、まず Hibernate を理解する必要があると思います。 (推奨学習: Java ビデオ チュートリアル )
両者の開発速度を比較すると、両者の特性やパフォーマンスだけでなく、どちらを基準に検討すべきかも考慮する必要があります。プロジェクトのニーズに合わせて選択します。プロジェクト開発により適しています。たとえば、プロジェクトでは基本的に複雑なクエリは使用されず、単純な追加、削除、変更、クエリのみです。このように、hibernate を選択する効率は非常に速く、なぜなら、基本的な SQL ステートメントはカプセル化されており、そこに行く必要はまったくありません。SQL ステートメントを作成すると時間を大幅に節約できますが、大規模なプロジェクトの場合は複雑なステートメントが多数あるため、休止状態を選択するのは良い選択ではありません。 mybatisを選択すると大幅に高速化され、明細管理もより便利になります。
第 2 の側面: 開発ワークロードの比較
Hibernate と MyBatis は両方とも、対応するコード生成ツールを備えています。シンプルで基本的な DAO レイヤー メソッドを生成できます。高度なクエリの場合、Mybatis では SQL ステートメントと ResultMap を手動で記述する必要があります。 Hibernate には優れたマッピング メカニズムがあるため、開発者は SQL の生成や結果のマッピングを気にする必要がなく、ビジネス プロセスに集中できます。
3 番目の側面: SQL 最適化
Hibernate クエリはテーブル内のすべてのフィールドをクエリするため、パフォーマンスの消費が発生します。 Hibernate は独自の SQL を記述して、クエリが必要なフィールドを指定することもできますが、これでは Hibernate 開発の単純さが損なわれます。 Mybatis の SQL は手動で記述されているため、必要に応じてクエリフィールドを指定できます。
Hibernate HQL ステートメントのチューニングには SQL を出力する必要がありますが、Hibernate の SQL はあまりにも醜いため、多くの人に嫌われています。 MyBatisのSQLは自分で手書きで書いているので調整が簡単です。ただし、Hibernate には独自のログ統計があります。 Mybatis 自体にはログ統計がなく、ログ記録には Log4j を使用します。
4 番目の側面: オブジェクト管理の比較
Hibernate は、オブジェクト状態管理 (状態管理) の機能を提供する、完全なオブジェクト/リレーショナル マッピング ソリューションです。基盤となるデータベース システムの詳細について心配する必要がなくなりました。つまり、SQL ステートメントを管理する必要がある一般的な JDBC/SQL 永続層ソリューションと比較して、Hibernate はより自然なオブジェクト指向の観点を採用して Java アプリケーションでデータを永続化します。
言い換えれば、Hibernate を使用する開発者は常にオブジェクトの状態に集中する必要があり、SQL ステートメントの実行を考慮する必要はありません。これらの詳細は Hibernate によってすでに処理されているため、システム パフォーマンスを調整するときに開発者だけがそれらを理解する必要があります。 MyBatis にはこの分野に関するドキュメントがなく、ユーザーはオブジェクト自体を詳細に管理する必要があります。
5 番目の側面: キャッシュ メカニズム
Hibernate キャッシュ
Hibernate の 1 次キャッシュはセッション キャッシュです。 1次キャッシュの使用 キャッシュでは、セッションのライフサイクルを適切に管理する必要があります。アクション操作ではセッションを使用することをお勧めします。一次キャッシュではセッションを厳密に管理する必要があります。
Hibernate の 2 次キャッシュは、SessionFactory レベルのキャッシュです。 SessionFactory のキャッシュは、内蔵キャッシュと外部キャッシュに分かれています。組み込みキャッシュには、SessionFactory オブジェクトの一部のコレクション属性 (マッピング要素データやスケジュールされた SQL ステートメントなど) に含まれるデータが格納されます。これはアプリケーションにとって読み取り専用です。外部キャッシュはデータベースのデータのコピーを保存するもので、一次キャッシュと同様の機能を持ちますが、二次キャッシュでは記憶媒体としてメモリを使用するほか、ハードディスクなどの外部記憶装置も使用できます。 2 次キャッシュは、プロセス レベル キャッシュまたは SessionFactory レベル キャッシュと呼ばれ、すべてのセッションで共有でき、そのライフ サイクルは、SessionFactory のライフ サイクルとともに存在し、消滅します。
MyBatis キャッシュ
MyBatis には、非常に簡単に構成およびカスタマイズできる非常に強力なクエリ キャッシュ機能が含まれています。 MyBatis 3 のキャッシュ実装には多くの改良が加えられ、より強力になり、設定が簡単になりました。
デフォルトでは、キャッシュは有効になっていません。ローカル セッション キャッシュに加えて、収益化を強化でき、循環依存関係を処理するためにも必要です。 2 次キャッシュを有効にするには、SQL マッピング ファイルに次の行を追加する必要があります:
文字通り、次のようになります。この単純なステートメントの効果は次のとおりです。
マッピング ステートメント ファイル内のすべての select ステートメントがキャッシュされます。
マッピング ステートメント ファイル内のすべての挿入、更新、削除ステートメントはキャッシュを更新します。
キャッシュは、最も最近使用されていない (LRU、最も最近使用されていない) アルゴリズムを使用して回復します。
スケジュール (フラッシュ間隔なし、リフレッシュ間隔なしなど) に従って、キャッシュは任意の時間順序でリフレッシュされません。
キャッシュには、リスト コレクションまたはオブジェクトへの 1024 個の参照が保存されます (クエリ メソッドが返す内容に関係なく)。
キャッシュは読み取り/書き込み (読み取り可能/書き込み可能) キャッシュとして扱われます。これは、オブジェクトの取得が共有されず、他の呼び出し元やスレッドの動作を妨げることなく呼び出し元が安全に変更できることを意味します。
これらのプロパティはすべて、キャッシュ要素のプロパティを通じて変更できます。
例:
このより高度な構成では、FIFO キャッシュが作成されます。 60 秒ごとに更新され、結果オブジェクトまたはリストへの 512 個の参照が保存されます。返されたオブジェクトは読み取り専用とみなされ、異なるスレッドの呼び出し元間でオブジェクトを変更すると競合が発生する可能性があります。利用可能なエビクション戦略は次のとおりです。デフォルトは LRU:
LRU - 最も最近使用されていない: 長期間使用されていないオブジェクトを削除します。
FIFO – 先入れ先出し: キャッシュに入った順序でオブジェクトを削除します。
SOFT – ソフト参照: ガベージ コレクターのステータスとソフト参照ルールに基づいてオブジェクトを削除します。
WEAK - 弱参照: ガベージ コレクターのステータスと弱参照ルールに基づいて、より積極的にオブジェクトを削除します。
flushInterval (更新間隔) は任意の正の整数に設定でき、適切な時間をミリ秒単位で表します。デフォルトは設定されていません。つまり、リフレッシュ間隔はなく、キャッシュはステートメントが呼び出されたときにのみリフレッシュされます。
size (参照数) は、キャッシュするオブジェクトの数と実行環境で利用可能なメモリ リソースの数に留意して、任意の正の整数に設定できます。デフォルト値は 1024 です。
readOnly (読み取り専用) プロパティは true または false に設定できます。読み取り専用キャッシュは、キャッシュされたオブジェクトの同じインスタンスをすべての呼び出し元に返します。したがって、これらのオブジェクトは変更できません。これにより、パフォーマンスに重要な利点がもたらされます。読み取り/書き込みキャッシュは、キャッシュされたオブジェクトのコピーを (シリアル化経由で) 返します。これは遅いですが安全なので、デフォルトは false です。
同様の点: システムのデフォルトのキャッシュ メカニズムを使用することに加えて、Hibernate と Mybatis の 2 番目のレベルのキャッシュは、独自のキャッシュを実装するか、他のサードパーティのキャッシュ ソリューション用のアダプターを作成することによって、キャッシュの動作を完全にオーバーライドできます。
相違点: Hibernate の 2 次キャッシュ構成は、SessionFactory によって生成された構成ファイルで詳細に構成され、キャッシュのタイプは特定のテーブルとオブジェクトのマッピングで構成されます。
MyBatis の 2 次キャッシュ構成は、特定のテーブルとオブジェクトのマッピングごとに詳細に構成されているため、テーブルごとに異なるキャッシュ メカニズムをカスタマイズできます。また、Mybatis は、Cache-ref を通じて、名前空間内の同じキャッシュ構成とインスタンスを共有できます。
両者の比較: Hibernate にはクエリ オブジェクトの優れた管理メカニズムがあるため、ユーザーは SQL を気にする必要はありません。したがって、2 次キャッシュの使用時にダーティ データが表示されると、システムはエラーを報告し、プロンプトを表示します。
この点で、MyBatis は 2 次キャッシュを使用するときに特に注意する必要があります。データ更新操作の範囲を完全に決定できない場合は、キャッシュを盲目的に使用することは避けてください。そうしないと、ダーティ データの出現により、システムの通常の動作に大きな隠れた危険がもたらされてしまいます。
Java 関連の技術記事をさらに詳しく知りたい場合は、Java 開発チュートリアル 列にアクセスして学習してください。
以上がマイバティスと冬眠の違いの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。