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

我们应用程序中的一项要求是对包括CRUD操作在内的所有内容实施“双重控制”。
明确地说，“双重控制”是一项功能，要求更改数据必须由更改请求者以外的其他人批准。因此，当用户对数据进行更改时，它不会直接提交给生产表。我知道有几种方法可以实现此目的（例如登台表），但那是其他时间。

有这样要求的问题，您认为我们应该遵循生成的Roo + GWT（使用RequestFactory）的标准“以数据为中心”的方式吗？

还是我们最好实现自己的基于“命令模式”的框架来支持双重控制？

我倾向于后者。我的直觉（基于与Roo + GWT进行3天的体验）表明，RequestFactory在设计时并未考虑双重控制，如果我们试图强行闯入，我们将陷入困境。在这里被证明是错误的。

最佳答案

您是否看过RequestFactory的ServiceLayerDecorator？它协调了有效负载处理与您的域对象和代码之间的所有交互。例如，您可以覆盖getProperty和setProperty方法，以读取和写入包含未决突变的某种“影子”日志。

如果需要为对象，方法或属性实现ACL，则可以使用loadDomainObject和resolveX方法来控制任何给定请求可以与哪些服务器端类进行交互。

要连接自定义装饰器，可以子类RequestFactoryServlet并调用two-arg构造函数。另外，您可以使用从SimpleRequestProcessor返回的对象实例化ServiceLayer.create()。

实施说明：RequestFactory的所有默认域交互行为都是使用一系列ServiceLayerDecorators构建的；如果您想查看构建ServiceLayerDecorator的示例代码，请查看GWT源代码。要注意的一件事是，如果您的装饰器调用ServiceLayer API中定义的任何方法，则它应使用getTop()提供的实例。预计ServiceLayerDecorator实例是无状态且可重用的，因此，如果需要在方法调用之间维护状态，请考虑使用ThreadLocal变量，类似于RequestFactoryServlet.getThreadLocalX()。

关于gwt - Spring Roo + GWT:如果每个数据操作都需要“双重控制”，那么RequestFactory还是走的路？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6396762/