ORM アプローチを全面的に使用できるのはどのような場合ですか、または使用する必要があるのはどのような場合ですか?

Question

ORM ツールを導入すると、アーキテクチャがよりクリーンになるはずだと私には思われますが、効率を高めるために、私はそれをバイパスし、JDBC 結果セットを反復処理することがあります。これにより、アーキテクチャがきれいになる代わりに、アーティファクトが調整されていない状態でもつれが生じます。

これは無効なコンテキストでツールを適用しているためでしょうか、それともそれよりも深いのでしょうか?

ORM アプローチを全面的に使用できるのはどのような場合ですか、または使用する必要があるのはどのような場合ですか?

ご洞察をいただければ幸いです。

---

背景を少し説明します:

私の環境には、約 50 台のクライアント コンピューターと 1 台のかなり強力な SQL Server があります。

50 クライアントすべてが常にデータにアクセスしているデスクトップ アプリケーションがあります。

プロジェクトのデータ モデルは、明確さ、効率性などのさまざまな理由から、何度も再編成されてきました。

私のデータモデルの歴史

1. JDBC が直接呼び出す
2. DAO + POJO、Pojo 間の関係なし (基本的に JDBC をラップ)。
3. Lazy Loading を実装する POJO 間の関係を追加しましたが、DAO 間呼び出しを非表示にするだけです
4. Hibernate がデータ アクセスをいかに「シンプル」にするか (POJO 間の関係が簡単になる)、また多くの関連エンティティを操作するときにデータベースへの往復回数を減らすことができることを知り、Hibernate の流行に飛び乗りました。
5. デスクトップ アプリケーションだったので、セッションを長期間開いたままにするのは悪夢であり、最終的には多くの問題を引き起こすことになりました。
6. 部分的な DAO/Hibernate アプローチに戻りました。これにより、Hibernate を使用しながら、DAO カーテンの背後で直接 JDBC 呼び出しを行うことができます。

Answer 1

アプリケーションが動作する場合、Hibernate はより意味があります。 オブジェクトグラフ, 、RDBMS に永続化されます。代わりに、アプリケーション ロジックがデータの 2 次元行列で動作する場合は、直接 JDBC 経由でデータをフェッチする方が適切に機能します。Hibernate は JDBC 上に記述されていますが、JDBC で実装するのは簡単ではない可能性のある機能を備えています。たとえば:

1. たとえば、ユーザーが UI で行を表示し、値の一部を変更した場合、実際に変更された列に対してのみ更新クエリを実行したいとします。
2. デッドロックに陥るのを回避するには、トランザクション内の SQL のグローバルな順序を維持する必要があります。JDBC を正しく理解するのは簡単ではないかもしれません
3. 楽観的ロックを簡単に設定できます。JDBC を使用する場合は、すべての更新クエリでこれを忘れずに使用する必要があります。
4. バッチ更新、コレクションの遅延実体化なども、JDBC で実装するのが簡単ではない場合があります。

（私は言う "かもしれない もちろんそれは可能です - そしてあなたはスーパーハッカーかもしれません:)

Hibernate では、必要に応じて独自の SQL クエリを実行することもできます。

これがあなたの決断に役立つことを願っています。

追伸：リモート デスクトップ クライアント上でセッションを開いたままにしておくことで問題が発生することは、実際には Hibernate の問題ではありません。DB への接続を長時間開いたままにすると、同じ問題が発生します。