Spring Roo + GWT：如果每个数据操作都需要“双重控制”，那么RequestFactory还是走的路吗？

如何解决Spring Roo + GWT：如果每个数据操作都需要“双重控制”，那么RequestFactory还是走的路吗？

| 在我们的应用程序中的一项要求是对包括CRUD操作在内的所有内容实施“双重控制”。 为了清楚起见，“双重控制”是一项功能，要求更改数据必须由更改请求者以外的其他人批准。因此，当用户更改数据时，它不会直接提交到生产表。我知道有几种方法可以实现此目的（例如，登台表），但这只是其他时间。 有这样要求的问题，您认为我们应该遵循生成Roo + GWT（使用RequestFactory）的标准“以数据为中心”的方式吗？ 还是我们最好实现自己的基于“命令模式”的框架来支持双重控制？ 我倾向于后者。我的直觉（基于与Roo + GWT进行3天的模拟测试）表明，RequestFactory的设计并未考虑双重控制，如果我们试图强行闯入，我们将陷入困境。在这里被证明是错误的。     

解决方法

        您看过RequestFactory的

ServiceLayerDecorator

吗？它协调了有效负载处理与您的域对象和代码之间的所有交互。例如，您可以覆盖

getProperty

和

setProperty

方法，以读取和写入包含未决突变的某种“影子”日志。 如果您需要为对象，方法或属性实现ACL，则可以使用

loadDomainObject

和

resolveX

方法来控制任何给定请求可以与哪些服务器端类进行交互。 要连接自定义装饰器，可以子类

RequestFactoryServlet

并调用two-arg构造函数。另外，您也可以使用从

ServiceLayer.create()

返回的对象实例化

SimpleRequestProcessor

。 实施说明：RequestFactory的所有默认域交互行为都是使用一系列“ 8”构建的；如果您想查看构建ѭ0的示例代码，请查看GWT源代码。要注意的一件事是，如果您的装饰器调用

ServiceLayer

API中定义的任何方法，则它应使用

getTop()

提供的实例。

ServiceLayerDecorator

实例应该是无状态且可重用的，因此，如果需要在方法调用之间维护状态，请考虑使用

ThreadLocal

变量，类似于

RequestFactoryServlet.getThreadLocalX()

。     ,        这实际上取决于您想要的“用户体验”，尤其是您是否希望用户验证已更改的内容的“差异”，还是批准“新版本”（快照）。 如果您需要差异，因为RequestFactory仅将差异（即用户或您对对象进行的代码实际更改）发送到服务器，则按Bob的建议截获

setProperty

调用肯定是这样做的一种方法（使Bob建议更清晰一些：您可以将差异“存储”到静态的

ThreadLocal

中，以便可以从服务电话中检索到它）。您还可以使用“更智能”的域对象，该域对象在调用其setter时会建立内部差异；然后，对象本身上的每个对象都可以访问diff。 如果需要快照，则只需实现服务即可将修改后的对象存储在“登台表”中或其他任何内容中，而不是存储在“生产表”中。然后在调用“批准”服务时将它们“移动”到“生产表”。 对我而言，很明显的一件事是，您必须围绕“双重控制”对服务和/或对象进行建模，而不要尝试在“简单的CRUD”操作（即“ “保存”不是“保存”，而是“发送批准”；并且有单独的“批准”操作）。