1

背景を説明すると、

  1. 複雑な関係を持つ何百ものテーブルで構成されるかなり大きなスキーマがあります。
  2. データ量も膨大で、データの性質は比較的機密性が高い (財務)
  3. 現在のアーキテクチャは - Java EE: セッション Bean、DAO (JDBC) 呼び出しストアド プロシージャです。
  4. データベース レベルでは、フロントエンド データベースとバックエンド データベース (異なるボックスでホストされている) とデータを同期させるためのレプリケーション メカニズムがいくつかあります。そのため、アプリケーションはフロントエンド データベースからデータを検索 (読み取り) する必要があり、利用できない場合はバックエンド DB を検索します。したがって、JPA 用語では、おそらく EntityManagers の 2 つの異なるインスタンスが必要です。

システムはまだ成長しているため、スケーラビリティとパフォーマンスが最大の懸念事項です。

上記の情報を基に、JPA などの永続化フレームワークを使用するようにアプリケーションを移行することがどの程度実現可能かについて、誰か意見はありますか? 上記の状況における持続性フレームワークの課題にはどのようなものがありますか?

4

3 に答える 3

5

より良いアドバイスを提供するために、誰かにアーキテクチャを深く調べてもらう必要があるという@ SJuan76に同意します。ただし、いずれにせよ、ここにいくつかのヒントがあります。

1) マッピングから始めます。エンティティを「正しい OOP の方法」でマッピングし、マッピングを微調整して同じスキーマに到達しようとします。関係がそれほど複雑な場合は、障害に直面する可能性があり、マッピング フェーズで対処することをお勧めします (PoC の場合、ごく一部をマッピングするのではなく)。

2) Hibernate のパフォーマンスについて心配する必要はありません。Hibernate はおそらく、どの社内 JDBC フレームワークよりも高速です。ただし、ビジネス ロジックをストアド プロシージャから Java コードに移動する場合は、パフォーマンスの変化を確認してください。通常、SP 内の大きなデータ セットを操作する方が、この大きなデータ セットをアプリ レイヤーに転送してそこで操作するよりも高速であるため、それらを変換するときに考え方を切り替える必要があります。

3) Hibernate の書籍やドキュメントを読む時間をとってください。本当。人々が Hibernate について不満を言うのは、ほとんどの場合、舞台裏で何が起こっているのかを本当に知らないからです。

幸運を ：-）

于 2012-07-13T07:54:30.967 に答える
1

あなたはストアドプロシージャを持っていると言いましたが、プロジェクトのほとんどを再実装したいかどうかという質問があります。

それを望まない場合は、JPA や Hibernate のことは忘れてください。その場合は、MyBatis (または iBatis) を使用することをお勧めします。

于 2012-07-13T13:20:42.790 に答える
1

私の経験では、数ページを過ぎると、ある種のフレームワークになってしまいます。これは、データのマップを交換するのと同じくらい簡単なことかもしれませんが、Java ではタイプ セーフを使用したいという要望から、何らかの形のマッピング フレームワークが必要になるでしょう。Hibernate は、その JPA アノテーションによって Java の世界で最もよく知られていますが、もちろん他の実装もあります。Grails についても素晴らしい経験がありました。Grails は実際に (デフォルトで) Hibernate を内部で使用していましたが、もちろんそれは完全なスタックです。

他のことをする前に、上級チームが時間をかけて、最も有望な代替案の少なくともいくつかからいくつかの例を検討することをお勧めします.

于 2012-07-12T19:01:55.837 に答える