こんにちは、永続化レイヤーに Spring JDBCTemplates、iBatis/myBatis、または Hibernate を使用するかどうかを決定する必要があるプロジェクトを開始しています。私はどちらの概念にも多かれ少なかれ精通していますが、現在人々が何を使用する傾向があるのか 疑問に思っています.
私の要件は次のとおりです。
前述のように、すべてをできるだけシンプルに保ちたいと考えています。私の好みは iBatis/myBatis に傾く傾向があります。これは、使いやすいように見え、実際の OR Mapper を必要としないためです。しかし、これらのフレームワークを使用している人々から学ぶことを本当に楽しみにしています。
spring/hibernate/ ibatisおよび JPA(2) のミニプロジェクト リバース エンジニアリング ソリューションを参照することをお勧めします。これは、開発要件を満たすためです。(まだ) 生成されないものが 1 つあります。それは jdbctemplate です。
テクノロジーを選択する前に、ミニプロジェクトのアプローチに適合するすべてのポイントを確認します。
しかし、判断できるのはあなたですので、あなたのモデルで試してみてください。start /bin/start-console.(cmd/sh) の可能性の概要を簡単に把握するには、データベースをポイントして生成トラックを選択します。データベースが (mysql、db2、oracle、hsqldb には hibernatedialect プリセットなどのデフォルト値がある) 場合、通常は数分かかります。さらに進めるには、構成を使用します (すべてのデータベース用です)。
どのテクノロジを使用するかについては、個人的にはすべての運用経験がありますが、hibernate などの orm フレームワークの双方向の側面は、単方向の sqlmap よりも優れていると考えています。構成を保存し、グラフのナビゲーションは直感的です。
良い点: ', などの特殊文字のエスケープは、orm フレームワークに含まれています。そして、これは、姓 = 'o'hara' の挿入など、sqlmap でネイティブ sql を実行しているときによく直面する問題です...
私は（あなたが言及した選択肢の中で）Hibernateに行きますが、JPA2に行きます（あなたがそれを含めた場合）。本当に生産性を高めたい場合は、コンパイル可能な基準 API 用のquerydslを統合します。
私は Ibatis と Hibernate を使ってきました。Ibatis は単純明快です。Hibernate は注意しないと複雑になる可能性がありますが、多くのことを行います。spring-jdbc は生の JDBC より優れています。
Hibernate の最大の利点は、さまざまなデータベースにマップできることです。スキーマ プレフィックスを無効にすることもできます。テスト用にインメモリ データベースを使用する、開発者に本番ターゲットとは異なるローカル データベースを使用させる (たとえば、Oracle をターゲットにしていてライセンスが問題である場合)、複数のデータベースをターゲットにできるなどのオプションがあります。Hibernate を使用すると、id ジェネレーターを簡単に交換できます。Hibernate ではネイティブ SQL がオプションですが、Ibatis では選択肢がありません。
また、Ibatis のマッピング ファイルを DRY に保つことも不可能ではありません。where句が異なる複数のクエリがある場合、カットアンドペーストが発生します。Hibernate では、重複はほとんどありません。
ところで、Ibatis と Hibernate はどちらも宣言型キャッシュ メカニズムを備えています。もちろん、Hibernate のほうがはるかに複雑です。
spring-jdbc は、私がリストした Ibatis の欠点をすべて共有しています。さらに、キャッシュメカニズムがないと思います。その主な利点は、JDBC オブジェクトが十分に隠されているわけではないため、必要に応じてより簡単に直接アクセスできることです。
Spring は 3 つの選択肢すべてと統合されます。Spring のサポートは差別化要因ではありません。
もう 1 つ: Hibernate は人工キーでうまく機能します。複合ビジネス キーを管理できますが、はるかに手間がかかります。Ibatis と spring-jdbc は、この問題が問題になるほど洗練されていません。
開発者が用心深く徹底していて、アプローチをシンプルに保つことができる場合 (たとえば、リクエストごとのセッションを使用する、セッション間でオブジェクトを保持しない、人工キーを使用するなど)、Hibernate を使用してください。Hibernate が提供するデータベースの抽象化が不要であると判断した場合、または開発者が優れたツールを使用することを信頼していないと判断した場合は、Ibatis を使用してください。ベアメタル jdbc の微調整が必要な特定のクエリを実行するためのフォールバックとして、spring-jdbc を念頭に置いてください。
ところで、Grails と GORM を使用すると Hibernate を簡単に試すことができます。セットアップ時間が大幅に短縮されるためです。Grails はメモリ内データベースから開始し、マッピング ファイルを作成しなくてもやり遂げることができます。
これら 2 つの目的のために: - すべてをできるだけシンプルに保つ - 簡単に習得して使用する
MyBatis と JdbcTemplate の両方が正常に動作します。どちらも、SQL を使用してデータベースにアクセスするための高レベル API を提供するだけです。
ほとんどのマッピング (結果セットからオブジェクトへ) を実行できるため、MyBatis を使用してコードを保存し、マッパー (メソッドを SQL ステートメントにマップする動的インターフェイス) を使用する場合はオブジェクトを保存します。
一方、手動でコーディングされたマッピングはイントロスペクションよりも高速であるため、おそらく JdbcTemplate で最高のパフォーマンスが得られます。
「最適な開発者の生産性」について。Hibernate は MyBatis/JdbcTemplate よりも生産性が高くなりますが、より多くのスキルと経験が必要です。
それらはすべてSpring 3と非常によく統合されています
iBatis は SQL マッピングのみを提供しますが、Hibernate は ORM に加えてネイティブ SQL クエリをマッピングする優れた簡単な方法を提供します。そのため、Hibernate にはより多くのオプションがあり、必要に応じて ORM またはネイティブ SQL を使用できます。そのため、私は Hibernate を好みます。
Hibernate は確実に Spring とうまく統合されます。iBatis もおそらく同様ですが、私はそのような統合を使用したことがありません。
これらは私の 2 セントです。誰かが異なる意見を持っている場合は、別の回答を投稿してください。
プレゼンテーション レイヤーがなく、ビジネス ルールの大部分が永続レイヤーの外にあるように思われるので、Spring の JDBCTemplate をお勧めします。Hibernate と Spring での経験が ibatis での経験をはるかに超える前に、私は ibatis を使用しましたが、提案する理由を以下に示します。
Hibernate - hibernate は永続化のための優れたフレームワークですが、 hibernate を最大限に活用するには経験のある人が必要です。一部の開発者は休止状態をブラック ボックスとして扱い、HQL に不注意になり、パフォーマンスに大きな問題を引き起こします。簡単に理解できる永続レイヤーを探しているので、これは避けます。 ただし、休止状態を使用しないと、休止状態がすぐに提供する単純なキャッシュシステムを失うことになります。図のヒントにキャッシング システムがないことは悪臭を放つため、パフォーマンスが重要な他のソリューションにキャッシング システムを統合することを検討します。
Spring -Spring の JDBCTemplates は、ほとんどの人にとって非常に簡単に理解できるはずです。これは新しいテクノロジーやフレームワークではなく、Spring の目標は単純に使いやすくすることです。あなたの要件の 1 つは Spring3 であるため、ほとんどのチームは依存性注入、行マッパー、および DTO の概念にすでに精通していると思いますか? どのソリューションを選択するにしても、Spring のトランザクション テスト ツールも利用します。最後に、JDBCTemplates を使用したパフォーマンスの問題のデバッグは、hibernate を使用するよりもはるかに簡単です。
iBatis - 私の iBatis の使用経験はほとんどないため、チームがこのツールで肯定的な経験を持っている場合にのみ、JDBCTemplates よりもこれをお勧めします。これは、他の 2 つのソリューションよりもやや人気が低いソリューションですが、良い中間点のように思えます。