java处理无法映射到SOA中一个frontendpage的错误

Question

我目前正在SOA中开发前端解决方案，在保存域对象时遇到了麻烦

后端给了我相当大的域对象，它们也被保存为一个整体。另一侧的前端将这些数据拆分为多个页面和子页面

在分享我的实际问题之前，我想提供一些背景信息：

我们系统中的大多数任务都是自动化的，使用流程引擎、与Web服务对话和规则引擎。只有当输入数据不正确时，才需要前端，以便人们需要更正它。前端中的输入由webservices保存，当用户认为一切都正确时，他将域对象传递回流程引擎

即将出现的问题的简单示例

域对象（基本上是根实体）

• 显示在页面A上的实体1（以及根实体中的一些字段）
• B页上显示的实体2

过程识别每个实体中的错误并标记它们。给用户一个任务，前端加载域对象，显示页面a。用户更正字段，当他移动到页面B时，输入应该被保存，这样他已经完成的工作就不会丢失

问题：

负责保存域对象的Web服务将抛出ValidationException，因为实体2仍有错误。您可能想知道，错误的数据最初是如何保存的？Web服务公开了两种用于保存的服务，一种叫做“自动”，另一种叫做“手动”。操作AutomaticsSave允许使用无效数据，因为流程引擎会为返回的每个错误创建标记。manualSave当前不允许出现错误

我正在寻找解决这个问题的建议

我认为这应该是SOA中相当常见的问题。如果我错了，请纠正我：-）

一种方法是，前端中的数据只存储在会话中，用户必须先修复所有错误，然后才能继续使用，但就可用性而言，我认为这不是最好的主意

另一个想法可能是在后端进行部分验证，但这为输入错误数据打开了大门

我的最后一个想法是将流程引擎标记的错误传递给manualSave，以便Web服务知道“嘿，这个字段以前有错误，所以我不会在只有无效时抛出ValidationException”

我期待着你的想法

[更新] 在初始答案之后，我更新了域对象的结构。这个问题似乎可以扩展到“如何设计一个好的Web服务”：-）

Answer 1

一些观察结果：

• （次要）名称automaticSave和manualSave可能会在界面中泄漏少量实现细节。这些名称似乎反映了幕后处理，而不是客户对正在发生的事情的想法
• （主修）同一个手动保存在不同上下文中调用两次（A页和B页）。在这两种情况下，客户机都提供Entity1和Entity2，表示每次应处理两个实体。这是误导&；低效的界面设计

我建议如下：

1. （次要）重命名自动保存为背景保存或保存请求。它执行异步处理（调用流程引擎）
2. （次要）将手动保存重命名为保存。它进行同步处理（验证、数据持久性、错误报告和方法内的返回响应）
3. （主要）将两个附加参数添加到保存操作（以及可选的后台保存操作）：IsEntity1更新&ISEntity2已更新布尔型和布尔型。仅当相应的标志为true时，才对每个实体执行验证、数据持久性和错误报告

优点：

• 促进灵活性、可重用性和；保存操作的可维护性——尤其是实体的验证。接口支持同步&；异步处理单数和复数；合并实体
• （次要）通过使用特定于客户的术语来加强封装
• 允许您遵循所需的用户工作流程—A页更正，然后保存实体1，然后保存实体2
• 良好的可用性——A页的更正不会因为B页的错误而被放弃（或缺少用户对B页的跟进）
• 在手动保存期间仍然可以抛出ValidationException，但仅适用于刚刚编辑的相关实体
• （次要）最大限度地减少网络流量-如果实体未更新，则可以传递空值，而不是传递将被忽略的未更新实体

Answer 2

我很想帮你，但我需要了解更多细节

The frontend is only needed when the input-data is incorrect so that a person needs to correct it. Input in the frontend is saved by the webservices and when the user thinks that everything is correct he passes the domain-object back to the process-engine.

你所说的域对象是什么意思？后端无法返回任何域对象，因为如果系统正确分层，域对象将保留在域层中，并且您正在与API层/服务层通信，因此最多只能得到域对象的表示。在你看来可能是一样的，但语义完全不同

所以当你得到一个表示域对象的对象时，你会谈论实体1和实体2，但它们是什么？什么是协议（REST、SOAP）

你们能不能给我们提供webservices的方法，你们提到的是验证服务和其他保存服务，所以我只想确保我了解一切

One way would be that the data in the frontend is only stored in the session and a user has to fix all errors before he can persist, but usability-wise I think thats not the best idea.

到目前为止，根据您的输入，这是唯一的方法，但不要忘记，您总是有两个验证阶段，在前端，在域中

谢谢

更新

我的答复如下：

In order to efficiently use a SOA, the architecture must meet the following requirements: Interoperability among different systems and programming languages that provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication depends on the concept of messages. Using messages across defined message channels decreases the complexity of the end application, thereby allowing the developer of the application to focus on true application functionality instead of the intricate needs of a communication protocol. Desire to create a federation of resources. Establish and maintain data flow to a federated database system. This allows new functionality developed to reference a common business format for each data element

在Fairness中，调用web服务的web服务就是SOA

Answer 3

我认为这里有几个问题。我看到的第一个问题是，在web服务上有两个不同的操作，对于您试图持久化的聚合来说，这两个操作是不同的。所谓聚合，我指的是在一个事务中保存域对象（作为一个整体）。最终，您的问题是，您没有为试图自动保存的实体强制执行不变量。自动保存和手动保存没有区别——您仍在保存。在一个操作中，你说可以忽略那些会使实体失效的属性，而在另一个操作中，你实际上是在强制执行不变量，如果你不包含这些数据，它就不是一个有效的域对象

我只能假设你这样做是为了获得域对象的部分持久性，这样你就可以适应多页步骤，你需要ID。自动保存操作会持久化部分域对象并返回一个ID，因此，您可以执行更新操作（手动保存），以确保实体正确完整地保存

我认为你最初的想法是将实体数据存储在内存中是一种更好的方法。我要补充的唯一一点是，服务持久化的聚合ID是在客户端创建的，而不是由后端系统创建的

这允许您在页面之间传递，并根据需要更新尽可能多的模型（实体1和实体2），以便持久化有效的聚合实体。每个视图模型都可以有自己的客户端验证，而不会影响其他视图模型（仍然可以使用作为备份运行的服务器端验证）

当您准备好保存域对象（作为一个整体）时，只需将视图模型（实体1和2）映射到它并保存即可。然后，您可以确定域对象已经考虑了所有不变量，并且应该保持不变，不会出现错误。鉴于您已经在客户机上创建了ID，因此不需要往返