0

ビジネスオブジェクトへのすべての変更を監査する必要があるシステムがあります。したがって、エンティティMyEntityにはNumberプロパティがあり、このフィールドを変更すると、システムは元のレコードをそのままにして、新しい数値で別のレコードを作成し、元のレコードをアーカイブ済みとしてマークします。 主キーNumberではありません。Versionエンティティの各バージョンを追跡するIdフィールドと、複数のバージョンにわたるオブジェクトIDを追跡するフィールドもあります。ここまでは順調ですね。

エンティティを削除すると、システムはレコードを削除せず、削除済みとしてマークするだけです。ここまでは順調ですね。

ここに問題があります。これで、クライアントのリストに多数のエンティティが含まれるようになり、ギャップが生じる可能性があります。

Item 1
Item 2
Item 3
Item 5
Item 6
...
Item 10

彼らは2つの新しいことをできるようになりたいと思っています。

  1. 番号5のアイテムを挿入し、後続のすべてのアイテムを番号を上にシフトします（5-> 6、6-> 7など）
  2. アイテムのギャップを折りたたんで、たとえば5-> 4の番号を付け直し、後続のすべてのアイテムを1つ下にシフトします。

これは私には本当に厄介なように思えます。通常、番号の変更は監査する必要があるため、そのようにすべての番号をまとめて変更することはできません。（さらに、各変更はスーパーバイザーによる承認が必要であり、変更を以前の監査状態に復元できるため、さらに複雑になります。）

さらに悪いことに、アイテム4は存在する可能性がありますが、アーカイブされた状態であるため欠落しています。後続のアイテムを折りたたむ場合、既存のアーカイブされたアイテムはどうなりますか？これらの状況を監査し、承認と復元を許可している間、これらの状況を処理するための合理的な方法がわかりません。誰もがこれを処理する方法を知っていますか？

4

2 に答える 2

0

ビジネスオブジェクトへのすべての変更を監査する必要があるシステムがあります。

Numberプロパティのこのルールの例外を提案してみてください。このプロパティが他の理由でも使用されており、とにかく監査する必要がある場合は、新しいフィールドOrderByNumberを提案して、監査要件をなくすことができます。

あなたの議論が抵抗に直面しているなら、私はNumberまたはOrderByNumberの名前をばかげているが明白なものに変更しようとします。それは人々を笑顔にし、彼らはポイントを見るでしょう：NotABusinessConcernNumberButUIElementNumberUsedForVisualOrdering。

ビジネスオブジェクトの監査ルールに例外を設ける方法がない場合は、UI /プレゼンテーションオブジェクトの別のレイヤーを作成し、2つの間のマッピングを維持する必要があります。

于 2012-02-27T21:55:52.993 に答える
0

私はこの問題を完全に満足のいく方法で解決したことはありませんでしたが、スーパー管理者のみが利用できる特別なモードを実装することでこれを処理しました。このモードでは、この種のID変更操作の監査が無効になっていますがNumber、主キーは必須のユーザーキーであり、これを変更すると、オブジェクトIDが新しいものに変更されます。これは白紙の状態から始まります。理想的ではありませんが、妥当な妥協点です。

于 2012-04-03T15:13:00.373 に答える