0

我有一个系统，必须审核对业务对象的所有更改。所以一个实体MyEntity有一个Number属性，当你改变这个字段时，系统会不理会原来的记录，并用新的数字值制作另一条记录，并将原来的记录标记为已归档。 Number不是主键。还有一个Version用于跟踪实体的每个版本的Id字段，以及一个用于跨多个版本跟踪对象身份的字段。到目前为止，一切都很好。

如果您删除实体，系统不会删除该记录，而只是将其标记为已删除。到目前为止，一切都很好。

这就是问题所在。现在客户端在列表中有一堆实体，并且可能存在差距：

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

他们希望能够做两件新的事情：

  1. 插入一个编号为 5 的项目，并将所有后续项目上移一个数字（5 --> 6、6-> 7 等）
  2. 折叠项目中的空白，例如，重新编号 5 --> 4，并将所有后续项目向下移动一个数字。

这对我来说似乎真的很讨厌，因为通常对数字的任何更改都需要进行审核，所以我不能像那样批量更改所有数字。（而且更加复杂，因为每次变更都需要得到主管的批准，并且变更可以恢复到之前的审核状态。）

更糟糕的是，项目 4 可能存在，但由于它处于存档状态而丢失。如果要折叠后续项目，应该如何处理现有的归档项目？在审核这些情况并允许批准和恢复时，我看不到处理这些情况的合理方法。有谁知道如何处理这个？

4

2 回答 2

0

我有一个系统，必须审核对业务对象的所有更改。

尝试为Number属性建议此规则的例外。如果此属性也用于其他原因并且无论如何都必须进行审计，那么您可以建议一个新字段OrderByNumber并使其免于审计要求。

如果您的论点面临阻力，我会尝试将 Number 或 OrderByNumber 重命名为荒谬但显而易见的名称。它会让人们微笑，他们会明白这一点：NotABusinessConcernNumberButUIElementNumberUsedForVisualOrdering。

如果您无法对业务对象的审计规则进行例外处理，那么您将不得不创建不同的 UI/表示对象层并保持两者之间的映射。

于 2012-02-27T21:55:52.993 回答
0

我从来没有以一种完全令人满意的方式真正解决过这个问题，但是我们通过实现一种特殊模式来解决这个问题，该模式仅对超级管理员可用，其中对这种身份更改操作禁用了审核，理由是Number, 而不是主键，是一个基本的用户键，如果你改变它，你就将对象身份更改为一个新事物，它从一个干净的状态开始。不理想，但合理的妥协。

于 2012-04-03T15:13:00.373 回答