春罗+ GWT：如果需要“双重控制”，RequestFactory 仍然是可行的方法吗？每次数据操作都需要吗？
我们的应用程序中的一项要求是对一切都实现“双重控制”，包括 CRUD 操作。 需要明确的是，“双重控制”是一项要求数据更改必须由更改请求者以外的其他人批准的功能。因此，当用户对数据进行更改时，它不会直接提交到生产表。我知道有几种方法可以实现这一点（例如临时表），但那是其他时间了。
问题是，有了这样的要求，您认为我们应该遵循标准的“以数据为中心”的方式生成Roo + GWT（使用RequestFactory）吗？
或者我们最好实施我们自己的基于“命令模式”的框架来支持双重控制？
我倾向于后者。我的直觉（基于 3 天的 Roo+GWT 测试）表明 RequestFactory 的设计并未考虑到双重控制，如果我们试图强行进入，我们会碰壁。我们会非常乐意在这里被证明是错误的。
One requirement in our application is to implement "dual control" for everything, including CRUD operations.
Just to be clear, "dual control" is a feature that requires a change in the data to be approved by someone other than the change requestor. So when a user make changes to data, it's not directly committed to production tables. I'm aware of several ways to implement this (e.g. staging tables) but thats for other time.
The question, with such requirement, do you think we should follow the standard "data centric" way of generated Roo + GWT (which uses RequestFactory) ?
Or we'll better off implementing our own "command pattern" based framework to support dual control?
I'm inclined toward the latter. My intuition (which based on 3 days play-around with Roo+GWT) says that RequestFactory is not designed with dual control in mind, and we'll hit a wall if we try to force our way in. Would be more than happy to be proven wrong here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您看过 RequestFactory 的
ServiceLayerDecorator？它调解有效负载处理与域对象和代码之间的所有交互。例如，您可以重写getProperty和setProperty方法来读取和写入某种保存待处理突变的“影子”日志。如果您需要为对象、方法或属性实现 ACL，则可以使用
loadDomainObject和resolveX方法来控制任何给定请求可以与哪些服务器端类进行交互。要连接自定义装饰器，您可以子类化
RequestFactoryServlet并调用两个参数的构造函数。或者，您可以使用从ServiceLayer.create()。实现注意事项：RequestFactory 的所有默认域交互行为都是使用一系列
ServiceLayerDecorators构建的；如果您想查看构建ServiceLayerDecorator的示例代码，请查看 GWT 源代码。需要注意的一件事是，如果您的装饰器调用ServiceLayerAPI 中定义的任何方法，它应该使用getTop()提供的实例。ServiceLayerDecorator实例应该是无状态且可重用的，因此如果需要跨方法调用维护状态，请考虑使用ThreadLocal变量，类似于RequestFactoryServlet.getThreadLocalX()。Have you looked at RequestFactory's
ServiceLayerDecorator? It mediates all interaction between the payload processing and your domain objects and code. As an example, you could override thegetPropertyandsetPropertymethods to read from and write into some kind of "shadow" log that holds pending mutations.If you need to implement ACLs for objects, methods, or properties, the
loadDomainObjectandresolveXmethods can be used to control which server-side classes any given request can interact with.To wire in a custom decorator, you can subclass
RequestFactoryServletand call the two-arg constructor. Alternatively, you can just instantiate aSimpleRequestProcessorusing the object returned fromServiceLayer.create().Implementation note: all of RequestFactory's default domain-interaction behavior is built using a series of
ServiceLayerDecorators; check out the GWT source if you want to see example code for building aServiceLayerDecorator. One thing to note is that if your decorator calls any methods defined in theServiceLayerAPI, it should use the instance provided bygetTop().ServiceLayerDecoratorinstances are expected to be stateless and reusable, so if you need to maintain state across method calls, consider usingThreadLocalvariables, similar toRequestFactoryServlet.getThreadLocalX().这实际上取决于您想要什么“用户体验”，特别是您是否希望用户验证已更改内容的“差异”，或批准“新版本”（快照）。
如果您想要差异，因为 RequestFactory 仅将差异（即用户或您编码对对象所做的实际更改）发送到服务器，那么按照 Bob 建议拦截
setProperty调用当然是一种方法这样做（为了让鲍勃的建议更清楚一些：您可以将差异“存储”在静态ThreadLocal中，以便您可以从服务调用中检索它）。您还可以使用“更智能”的域对象，它们在调用其 setter 时构建内部差异；然后，每个对象都可以访问该对象本身的差异。如果您想要快照，那么您只需实现服务以将修改后的对象存储在“临时表”或其他内容中，而不是“生产表”中；然后在调用“批准”服务时将它们“移动”到“生产表”。
（对我来说）很清楚的一件事是，您必须围绕“双重控制”对服务和/或对象进行建模，而不是尝试在“简单的 CRUD”操作中进行操作（即“保存”不是“保存”） ，这是一个“发送批准”；并且有一个单独的“批准”操作）。
It really depends what "user experience" you want, and particularly whether you want users to validate "diffs" of what has been changed, or approve the "new version" (snapshot).
If you want diffs, because RequestFactory only sends diffs (i.e. the actual changes the user, or you code, made to the objects) to the server, then intercepting
setPropertycalls as suggested by Bob is certainly one way to do it (to make Bob suggestion a bit clearer: you'd "store" the diff in a staticThreadLocalso you can retrieve it from your service call). You could also use "smarter" domain objects, that build an internal diff when their setters are called; the diff would then be accessible for each object on the object itself.If you want snapshots, then you simply have to implement your services to store the modified objects in "staging tables" or whatever rather than in the "production tables"; and then "move" them to the "production tables" when the "approve" service is called.
One thing that's clear (to me), is that you have to model your services and/or objects around "dual control" and not try to do it within "simple CRUD" operations (i.e. the "save" is not a "save", it's a "send for approval"; and there's a separate "approve" operation).