JDBC VS Hibernate
WebアプリケーションでJDBCを非常に長い間使用しています。私たちがそれを使用した主な理由は、コード、SQLを100％コントロールし、手で物事を修正するからです。それとは別に、データベース内でトリガーを使用しました。データベースはDBの専門家によって個別に開発されています。
しかし、多くの人がHibernateの使用を推奨しているため、使用することも考えました。しかし、以下の問題が見つかりました。
Hibernateは「既存の」データベースに接続できません。常に独自のものを作成しようとします。
データベースは、異なるプラットフォーム（クラウド、サーバー、VPS、パーソナルコンピューター）にある同じアプリケーションからアクセスできます。 Hibernateは、この状況でのキャッシュのために問題を起こす可能性があります。
「テーブル作成作業」をJavaコードに与えるのは好きではありません。常に手動でテーブルを作成します。
非常に長く複雑なSQLステートメントを使用する必要がある場合があります。前回、150行を超えるステートメントを使用して、20を超えるテーブルを結合しました。 Hibernateに関しては、これで問題に直面するかどうか疑問です。
私たちのSQLコードは素晴らしく、標準です。 Hibernateで生成されたコードは、私たちにとって少し汚いようです。
常にMySQLを使用します。他のDBを使用しないでください。
作成するアプリケーションには、医療に関連する最大限のセキュリティが必要です。少なくとも1つのデータレコードがリークした場合、処理は完了です。
データベースには多くの
foreign keys、Primary Keys、Composite Keys、Unique Keysなどがあります。フォーラムで、Hibernateがそれらを台無しにしたと不満を言う人もいました。「ソフトウェアエンジニアですか？すでに死んだ
JDBC!!。を使用しています」と主張する人がいるため、休止状態を試すことにしました。
これらを考慮して、上記のポイントが実際に真実であるかどうかを教えてください（私が言ったように、グーグルや議論などでそれらを知りました）。また、Hibernate VSの長所と短所は何ですかJava JDBC？
上記の問題への回答：
1。 Hibernateは「既存の」データベースに接続できません。常に独自のものを作成しようとします。
これは間違っています。 Hibernatecanは既存のデータベースに接続しますが、常にデータベースを再作成しようとはしません。 hbm2ddl. autoのようなパラメーターをオフにするだけです。
2。データベースは、異なるプラットフォーム（クラウド、サーバー、VPS、パーソナルコンピューター）にある同じアプリケーションからアクセスできます。 Hibernateは、この状況でのキャッシュのために問題を起こす可能性があります。
Hibernateには調整可能なキャッシュがあるため、これも問題ではありません。
3。 「テーブル作成作業」をJavaコードに与えるのは好きではありません。常に手動でテーブルを作成します。
問題ない。上記p.1をご覧ください。さらに、間接的なテーブルの作成と更新に便利なライブラリがいくつかあります（例： liquibase ）。これらは完全に休止状態と組み合わせて使用できます。
4。非常に長く複雑なSQLステートメントを使用する必要がある場合があります。前回、150行を超えるステートメントを使用して、20を超えるテーブルを結合しました。 Hibernateに関しては、これで問題に直面するかどうか疑問です。
必要に応じて、いつでも直接JDBC呼び出しを使用し、休止状態を介してネイティブSQLクエリを呼び出すことができます。
5。私たちのSQLコードは素晴らしく、標準です。 Hibernateで生成されたコードは、私たちにとって少し汚いようです
繰り返しますが、自動生成された休止状態ではなく、複雑なSQLコードを呼び出す必要がある場合は、それを実行できます。
6。常にMySQLを使用します。他のDBを使用しないでください。
まったく問題ありません。 Hibernateは特別なMySQLダイアレクトをサポートしています：org.hibernate.dialect.MySQLDialect。
7。作成するアプリケーションには、医療に関連する最大限のセキュリティが必要です。少なくとも1つのデータレコードがリークした場合は、完了です。
セキュリティの問題は、ORMテクニックとは関係ありません。 Hibernateは、純粋なデータベースJDBC呼び出しとプログラマーツールの間の単なる論理的で便利なオブジェクト指向レイヤーです。一般的なネットセキュリティには何の影響もありません。
Hibernateは素晴らしいツールであり、多くの documentations 、 books 、および blog article を見つけることができます。
すべての懸念に対処します。
Hibernateは「既存の」データベースに接続できません。常に独自のものを作成しようとします。
Hibernateは、 統合テスト であっても、別個のデータベーススキーマ管理手順を使用する必要があります。 FlywayDB のような増分バージョン管理ツールを使用して、スキーマの変更を管理する必要があります。
データベースは、異なるプラットフォーム（クラウド、サーバー、VPS、パーソナルコンピューター）にある同じアプリケーションからアクセスできます。 Hibernateは、この状況でのキャッシュのために問題を起こす可能性があります。
サードパーティのキャッシュ実装を使用する2次キャッシュを使用する必要はありません。すべてのキャッシングソリューションが壊れる可能性があります トランザクションの一貫性 。一次キャッシュは session-level repeatable 読み取りを保証し、オプティミスティックロックを使用すると lost updates を防ぐことができます。
「テーブル作成作業」をJavaコードに与えるのは好きではありません。常に手動でテーブルを作成します。
データベース管理は、ORMツールから分離する必要があります。とにかくそれがベストプラクティスです。
非常に長く複雑なSQLステートメントを使用する必要がある場合があります。前回、150行を超えるステートメントを使用して、20を超えるテーブルを結合しました。 Hibernateに関しては、これで問題に直面するかどうか疑問です。
Hibernateは、書き込み操作および同時実行制御に最適です。高度なクエリ（ウィンドウ関数、CTE）にはネイティブSQLを使用する必要があります。ただし、Hibernateではネイティブクエリを実行できます。
私たちのSQLコードは素晴らしく、標準です。 Hibernateで生成されたコードは、私たちにとって少し汚いようです。
必要はありませんし、とにかくhbmdllユーティリティを使うべきではないでしょう。
常にMySQLを使用します。他のDBを使用しないでください。
それはさらに良いです。したがって、データベースの移植性の問題を気にすることなく、高度なネイティブクエリを使用できます。
作成するアプリケーションには、医療に関連する最大限のセキュリティが必要です。少なくとも1つのデータレコードがリークした場合、処理は完了です。
Hibernateは、データベースまたはデータアクセスコードのセキュリティ保護を妨げません。 Hibernateでもデータベースのセキュリティ対策を使用できます。 Jasypt を使用して、あらゆる種類のセキュリティ関連機能を有効にすることもできます。
- 高度なパスワードハッシュ
- 双方向暗号化
データベースには、外部キー、主キー、複合キー、一意キーなどがたくさんあります。フォーラムで、Hibernateがそれらを台無しにしたと不満を言う人もいました。
これらはすべてHibernateによってサポートされています。 JPAの規約とは別に、Hibernateは 特定のマッピング をエキゾチックなマッピングに提供します。
「ソフトウェアエンジニアですか？すでに死んだJDBCを使用しています!!」と主張する人がいるため、休止状態を試すことにしました。
これは、既にマスターしているライブラリから切り替えるための正しい議論ではありません。 Hibernateを使用することでメリットが得られると思われる場合、それがJDBCからの切り替えの唯一の魅力的な理由です。
プレーンで古いJDBCを使用することは、IT業界に欠けていることを意味するのではなく、Hibernateは基礎となるレイヤーでJDBCを使用します。
どんな利点があるのか、私たちは何を探さなければならないのか。
1.）Cacheメカニズム。
2.）sessions、transactionsなどの管理.
3.）クエリの作成の労力を減らし、Query API、Criteria API、HQL
あなたが提起した質問は、多かれ少なかれ Hibernate docs でカバーされています。
また、ehcache、infinispan、利用可能なキャッシング戦略がはるかに多くあり、デプロイしているサーバー、JBOSS、Weblogic、Tomcatなどに依存します。クラウド、分散キャッシュなどの++環境。
Hibernateには、スキーマの自動作成をオフにして、作成したスキーマを指定するオプションが引き続きあります。
ここに私が知っている簡単な答えがあります
1）既存のデータベースに接続できます。しかし、そうです ここ
ソリッドオブジェクトモデルがない場合、Hibernateは恐ろしい選択だと思います。
2）データベースは異なるアプリケーションからアクセスされるため、ロックを維持できます。一方で、trun-offキャッシングを行うことができます here 。
3）テーブルを手動で作成し、.hbm.xmlファイルを使用して接続できます。
4）単純なSQLクエリ条件など、Hibernateでは任意のタイプのクエリを使用できます。
5）必要に応じて、HibernateでSQLコードを直接使用できます。他のオプションは、基準を使用することです。
6）HibernateはDB固有ではありません。任意のデータベースにアクセスして、休止状態に接続できます。
7）ロックを使用し、データベースで権限を付与すると、セキュリティを維持できます。
8）Hibernateで外部キーが乱雑であることに同意しました適切に処理しない場合。したがって、OOアプローチを使用し、カスケードを適切に維持すれば、Hibernateが適切な選択になります。