2

Martin Fowler が「Unit of Work」パターンと呼んでいるものに似たものを設計して実装する必要があります。他の人がそれを「ショッピング カート」パターンと呼んでいると聞いたことがありますが、ニーズが同じであるとは確信していません。

具体的な問題は、ユーザー (および UI チーム) が、親オブジェクトが作成される前に、(データベース内の参照整合性制約を使用して) 子オブジェクトを作成して割り当てることができるようにしたいということです。今日、別のデザイナーと会い、2 つの代替アプローチを考え出しました。

a) まず、データベースにダミーの親オブジェクトを作成し、次にダミーの子とダミーの割り当てを作成します。負のキー (通常のキーはすべて正のキー) を使用して、データベース内の羊とヤギを区別できます。次に、ユーザーがトランザクション全体を送信すると、データを更新し、実際のキーを追加して調整する必要があります。

これにはいくつかの欠点があります。

  • これは、インデックスに摂動を引き起こします。
  • それらを持つ列の一意の制約を満たすために、何かを考え出す必要があります。
  • 多くの既存の SQL と SQL を生成するコードを変更して、多くの WHERE 句にさらに別の述語を追加する必要があります。
  • Oracle で主キーを変更することはできますが、それは困難です。

b) これらのリバース トランザクションに参加できるようにする必要があるオブジェクトと割り当ての一時テーブルを作成します。ユーザーが [送信] をクリックすると、実際のエントリが生成され、古いエントリが消去されます。

これは最初の方法よりもクリーンだと思いますが、それでもデータベース アクティビティのレベルが高くなります。

どちらの方法でも、ユーザーが送信要求またはキャンセル要求を実行する前にセッションが失われた場合、一時データを期限切れにする何らかの方法が必要です。

誰かがこの問題を別の方法で解決しましたか?

よろしくお願いします。

4

1 に答える 1

1

トランザクションがコミットされる前にこれらのオブジェクトをデータベースに作成する必要がある理由がわかりません。そのため、解決策を進める前に UI チームに確認することをお勧めします。ユーザーが以前に別のページに保存した情報を読むことだけが目的であることに気付くかもしれません。

したがって、コミット前にオブジェクトをデータベースに格納する必要がないと仮定して、プラン C を示します。

初期化されたビジネス オブジェクトをセッションに格納します。その後、必要なすべての子を作成し、トランザクションをコミットする必要がある場合にのみデータベースにアクセス (および参照を設定) できます。セッション データが (個別にまたは集合的に) 大きくなる場合は、セッション情報をデータベースに保存します (既に行っている可能性があります)。

于 2009-10-05T17:56:49.680 に答える