如果需要批准才能实际进行更改,如何保存对象?

时间:2008-12-11 19:56:56

标签: c# nhibernate

所以我有一个对象图,让我们说它是一个订单。您有订单类,订单项类,跟踪编号类,付款类。你明白了。

现在业务要求是任何用户都可以更改订单,但订单更改必须由经理批准。直到经理批准没有任何变化。管理人员可以随时更改任何内容,无需批准。

处理此类情况的最佳做法是什么?保存订单对象的许多(可能的)不同状态,并最终批准或拒绝更改。

我正在使用C#和Nhibernate。

谢谢,凯尔。

8 个答案:

答案 0 :(得分:2)

我会创建一个事务表。它将记录每个待定的更改。它会引用订单表。

所以订单会被创建,但有一个挂起的变化;记录将被插入到订单表中,状态列为pending,并且记录将被插入OrderTransaction表中。

对于每次更改,其他记录都会插入到OrderTransaction表中。

我还会设置一个RequestedChanges表,其中包含所有可能的请求更改。

答案 1 :(得分:2)

类似于Sam WIlliamson关于交易表的想法,我会使用临时表。

非经理人员所做的更改,转到临时表中的新订单对象。经理将有一个界面来审查这些待批准的订单,系统将已经保存了所有更改,但超出了标准位置。

这也可能是用户界面的一个问题,他们必须同时看到订单的正式版本和待定修订版本才能理解对象的状态。

无论如何,我认为你最好的选择是正常存储对象,但是在官方记录的单独表格中,由经理审查。这个临时表永远不会变得非常大,因为它代表了经理必须得到的批准积压。

答案 2 :(得分:1)

我对nHibernate没有任何经验。

对于这样的场景,最好留给数据库来存储Order(state = ForManagerToApproveOrReject),然后可以查询它以查看哪些Orders正在等待批准/拒绝(来自经理的视图)

然后经理可以批准/拒绝它。 保存Order(ApprovedOrder,RejectedOrder)的继承模式似乎有些奇怪。

答案 3 :(得分:1)

一个简单的解决方案就是创建另一个订单,该订单是应用了更改的原始副本,状态设置为PendingApproval,以及自动增量VersionNumber。更改表的主键以包括ApprovalDate。然后,当前批准的订单始终是具有最近批准日期的订单。

答案 4 :(得分:1)

如果订单在批准之前没有完成,您可能希望拥有挂单和已完成的订单表结构。待处理订单可能只是序列化对象,只能按订单写入,订单行等一旦批准。

如果您允许在批准后更改订单变得更加复杂,您可能还需要考虑到过帐批准步骤,收到的付款,拣货,包装,运输等。

有很多方法可以做这种事情,你如何做到这将取决于真正的业务需求。即你说管理人员可以随时更改订单,但他们是否真的可以更改已发货的订单?

答案 5 :(得分:0)

我理解这一部分,我所遇到的问题是在订单未获批准的情况下确定如何/在何处保存所有更改。例如,用户A添加付款,用户B更改地址,用户C添加新订单项。

直到经理批准订单保持最初创建(或从DB检索)。经理处于批准屏幕后,他/她可以批准/拒绝每个更改。更改将写入原始订单并保留审核。用户A在za at aaa批准的yyy上更改了xxx。

答案 6 :(得分:0)

你所描述的是一个工作流程,它实际上听起来像Windows Workflow Foundation的好候选人。如果您的工作流程对业务至关重要,我倾向于将其与数据库逻辑分开,WWF将允许您执行此操作。

答案 7 :(得分:0)

感谢所有答案。实际的业务用例不是创建订单,但如果我试图解释实际业务,我必须写几段。最重要的是管理者需要在深度嵌套的对象图上“变为现场”之前对其进行调整。

我喜欢交易表的想法。

我也喜欢保存两个版本的“订单”,一个包含更改,一个没有。

我想我必须深入研究两者,看看会发生什么。