Java 设计问题：UI层是否应该担心它；什么是后端？

这更多的是一个设计和架构问题。

我正在为旧系统开发一个新的UI层。该系统接受特定xml格式的请求。当前，来自新UI层的请求通过控制器传递到数据处理类。

此

转换器/消息处理类

将UI请求xml转换为所需的请求格式。它向从UI层接收到的XML中添加了一些不推荐的元素和常量

来自UI的请求XML部分类似于实际的后端。但是它必须转到

翻译/消息处理
类才能转换为实际请求。

我的问题是，UI层是否需要担心其请求XML是否部分类似于实际请求？UI层是否可以将JSON格式的数据发送到
转换器/消息处理
，转换器类将其转换为实际的请求xml

我的问题是，UI层是否需要担心其请求XML是否部分类似于实际请求？UI层是否可以将JSON格式的数据发送到massaging类，massaging类将其转换为实际的请求xml

显然，它可以做到这一点。但这意味着“按摩”课程还有更多的工作要做

在我看来，你可能问错了问题。如果我站在你的立场，我会问自己为什么不能直接使用“旧”系统的请求格式，或者为什么不能更改“旧”系统以直接接受“新”格式的请求

或者换一种说法，问问自己实现新格式的目的是什么，以及所有额外的编码和“按摩”的性能影响

除非有其他事情你没有告诉我们，否则这些对我来说都有点不必要。
想想服务服务器提供并由客户端使用的任何功能都应该由服务接口抽象，这样使用此服务的代码就不必担心其实现或涉及的任何协议。然后，您可以在服务器上获得实际实现，并在客户端获得远程facade实现，后者将请求转发给服务器并处理响应：

interface SomeService {
    public SomeResult doSomething(SomeArguments) throws SomeException; 
}

class SomeServiceServerImpl implements SomeService {
    // server-side implementation
}

class SomeServiceClientFacade implements SomeService {
    // client-side facade, forwards the request, for example to a web service
}

然后，facade可以将参数转换为XML，调用web服务，解析XML响应并将其转换回结果对象或异常

如果您使用标准化的RPC（远程过程调用）协议（如SOAP或），处理此问题的最优雅方法是使用带有
调用处理程序
的调用处理程序，该调用处理程序以通用方式进行请求和响应解组，从而允许您廉价地创建远程服务代理

我的问题是，UI层是否需要担心其请求XML是否部分类似于实际请求

不会。正如您在下一个问题中所建议的，消息传递类可以将GUI数据转换为实际的XML请求

UI层是否可以将JSON格式的数据发送到消息传递类，消息传递类将其转换为实际的请求XML

可以。但是，您的GUI应该有一个数据模型。GUI将与数据模型交互。数据模型将与消息传递类交互。不需要另一种数据格式，除非您没有告诉我们某些要求。
原因1：旧系统无法更改，因为它庞大而顽固。要想弄清楚这些变化的影响需要很多时间。原因2：它接受的请求XML非常大，有很多常量和不推荐使用的元素。试图让新的UI尽可能轻巧，这样它也可以在更小的设备上工作。是的，你们对数据模型的看法是绝对正确的。这些表单遵循数据模型，我称它们为
UIModels
。将每个UIModel视为一个VO对象。现在，
Translator
或
Massaging
类负责将这些
UIModel
xml放在适当的位置，并使用常量元素匹配请求xml。听起来不错？@Himanshu Yadav：只要你的GUI组件可以在你的UIModels中获取或设置字段，是的。还有一个疑问。这些UI模型实际上是表示VO对象的UIModel XML。目前，我确保所有字段
name
attributes值与UIModel XML元素匹配。
然后使用表单值构建XML。此表单XML与模型XML相同。我可以用与模型XML匹配的表单值构建一个JSON对象吗？听起来合适吗？@Himanshu Yadav:我不明白为什么你的GUI模型不能是普通的旧Java对象（POJO）？实际上我正在构建一个可配置的UI容器。它将帮助业务分析师构建自己的表单。这些UI模型XML仅供参考。所以他们给出了正确的字段名。我想说，这是一个特权客户端。因为这个UI层是EAR的一部分。