2

ORM ツールを導入すると、アーキテクチャがよりクリーンになると思われますが、効率化のために、ORM ツールをバイパスして、JDBC Result Set を反復処理することが時々あります。これは、よりクリーンなアーキテクチャではなく、調整されていないアーティファクトのもつれにつながります。

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

ORM アプローチを完全に独り占めできるのはいつですか?

どんな洞察も大歓迎です。

背景の少し:

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

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

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

私のデータモデルの歴史

  1. JDBC が直接呼び出す
  2. Pojo 間の関係のない DAO + POJO (基本的に JDBC をラップ)。
  3. 遅延読み込みを実装する POJO 間の関係を追加しましたが、DAO 間の呼び出しを非表示にするだけです
  4. Hibernate の時流に飛び乗ったのは、Hibernate の時流に飛び乗ったのは、Hibernate がデータ アクセスをいかに「シンプル」にするか (POJO 間の関係が些細なものになった) を見てからでした。
  5. セッションを長期間開いたままにしておくのはデスクトップアプリケーションだったので悪夢だったので、最終的には多くの問題を引き起こしました
  6. Hibernate を使用しながら、DAO カーテンの背後で直接 JDBC 呼び出しを行うことができる、部分的な DAO/Hibernate アプローチに戻りました。
4

1 に答える 1

4

Hibernate は、RDBMS に永続化されているオブジェクト グラフでアプリケーションが動作する場合に、より意味があります。代わりに、アプリケーション ロジックがデータの 2-D マトリックスで動作する場合は、直接 JDBC を介してそれらをフェッチする方がうまく機能します。Hibernate は JDBC の上に書かれていますが、JDBC で実装するのは簡単ではない機能を備えています。例：

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

（私は「自明ではないかもしれない」と言います。それはもちろん実行できるからです - そしてあなたはスーパーハッカーかもしれません:)

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

これが決定に役立つことを願っています。

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

于 2008-09-12T03:59:42.520 に答える