一组对象及其状态的修改和回滚方法
在我正在编写的系统中,我有包和服务对象的概念。
程序包是服务集合的容器,并且具有一组内在的可配置限制。这些限制包括:
- 支持哪些类型的服务
- 可以分配给包的服务数量
- 需要在所述服务中设置为特定值的属性
需要能够在兼容包之间升级和降级。通过这样做,需要转移、修改包内的服务,并可能创建或删除以满足新包的约束。
这需要在收取任何资金之前完成,以确保将某些独特的资源分配给服务(并进行隔离)。
问题来了,如果支付失败,升级被取消,我们如何回滚修改,回到之前的状态呢?
可能会出现以下(非详尽的)问题列表:
- 通过删除不再与新包兼容的服务,可以释放唯一的约束,然后由其他包(在其他帐户等中)使用,从而阻止可能的回滚
- 服务被删除的服务很难在引用完好无损的情况下恢复
- 如果服务未被删除,它们将继续消耗其他类似服务可能需要使用的独特约束
目前处理此问题的方法是通过一组特定于包的步骤存储对象(而不是删除它们),并保存在回滚时恢复状态的步骤列表。然而,这是根据具体情况完成的,容易出错并且感觉很笨拙。
我想知道你们中是否有人遇到过类似的事情并且知道可以在这里使用的模式或方法。基本上,我们需要能够更新一组对象的状态,提交更改,但可以选择回滚到以前的版本。注意:在系统内,对象的状态可以被序列化和存储。
任何“我不会那样做!”感谢收到有关替代方案的意见。
下面是一个示例:
升级前:
升级后:< /strong>
In a system I am writing, I have the concept of package and service objects.
A package is a container for a collection of services, and has an intrinsic set of configurable restrictions. These restrictions include:
- Which types of service are supported
- The number of services that can be allocated to the package
- The properties that need to be set to specific values within said services
There is a need to be able to upgrade and downgrade between compatible packages. By doing so, the services within the package need to be transferred, modified and potentially created or deleted to meet the constraints of the new package.
This needs to be done before any money is taken to ensure that certain unique resources are allocated to the services (and ring-fenced).
The problem comes if payment fails and the upgrade is cancelled - how do we rollback the modifications and return to the previous state?
The following (non-exhaustive) list of issues could arise:
- By deleting services that are no longer compatible with the new package, unique constraints could be released which are then used by other packages (in other accounts etc.) stopping rollback being possible
- Services that are deleted are difficult to restore with references intact
- If services aren't deleted, they continue to consume unique constraints that might need to be used by other similar services
The way this is handled at the moment is through a package-specific set of steps that store objects out of the way (rather than deleting them), and hold a list of steps to restore state back in the event of rollback. However, this is done on a per-case basis, is error-prone and feels clunky.
I was wondering if any of you had encountered anything similar and knew of a pattern or methodology that could be employed here. Basically we need to be able to update the state of a set of objects, commit the changes, but have the option to rollback to a previous version. NB: Within the system the state of objects can be serialised and stored.
Any "I wouldn't do it like that!" comments gratefully received with alternatives.
Here is an example:
Before upgrade:
After upgrade:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
做了类似的事情,但是非常快。
为了执行“撤消”/“回滚”,您需要做一些事情:
[1] 在执行之前存储/注册/序列化给定对象(“Package”和“Service”)的值操作。
如果操作成功,该信息可能会被丢弃,或者只是存储为历史数据。否则,使用它将对象返回到之前的状态。
您可能还想注册新的更改。
[2] 您必须注册您的应用程序可以完成的菜单或操作集合,
并最终回滚。
例如,如果您执行的是 Paint 程序,而不是“package-and-services”应用程序。
在您的应用程序中,您将有一组动作或操作,其中一个操作是“绘制填充方块”。
[3] 每次执行这些操作之一时,即使重复,您也会有一个可以完成或回滚的每个操作的寄存器或日志。
当您执行“画图”应用程序时,您会多次使用“画图填充平方”。
[4] 您需要在列表中进行相反的操作,以恢复匹配的操作。
使用以前的画图应用程序。例如,您应该有一个“恢复填充的平方”操作,该操作会保留该区域,就像用户绘制填充的平方之前一样。
不要关心它是如何完成的,关心应该有一个匹配的。
[5] 匹配的相反操作也必须记录在日志中。
Done something similar, but, very quickly.
In order to perform an "undo" / "rollback", you need to do some things:
[1] To store / register / serialize the value of the given objects ("Package" and "Service" (s) ), before performing the operation.
If the operation succedes, that info could be discarted, or just stored as historical data. Otherwise, use it to return the objects to the previous state.
You may also want to register the new changes.
[2] You have to register a menu or collection of operations that can be done by your app,
and eventually rollback.
For example, if instead of the "package-and-services" application, you where doing a Paint program.
In your application, you'll have a collection of actions or operations, and one of that operations is the "Paint filled square".
[3] Each time you execute one of those operations, even, if duplicated, you have a register or log of each operation that can be done, or rollback.
When you execute you Paint app., you use the "paint filled squared", several times.
[4] You need, in your list a opposite operation, that restores the matching one.
Using the previous Paint app. example, you should have an "restore filled squared" operation, that leaves the area, as before the user painted the filled squared.
Don't care how its done, care about that there should be a matching one.
[5] The matching opposite operation must be registered in the log, also.