0

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

我正在为旧系统开发新的 UI 层。该系统接受特定 xml 格式的请求。当前来自新 UI 层的请求通过控制器发送到数据按摩类。

这Translator/Massaging class会将 UI 请求 xml 转换为所需的请求格式。它向从 UI 层接收的 XML 添加了一些不推荐使用的元素和常量。

来自 UI 的请求 XML 部分类似于实际的后端。但它必须到Translator/Massaging类才能转换为实际请求。

我的问题是 UI 层是否需要担心它的请求 XML 是否与实际请求部分相似？UI 层是否可以将 JSON 格式的数据发送给Translator/Massaging翻译器类，然后将其转换为实际的请求 xml？

4

3 回答 3

1

我的问题是 UI 层是否需要担心它的请求 XML 是否与实际请求部分相似？

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

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

它可能。但是，您的 GUI 应该有一个数据模型。GUI 将与数据模型交互。数据模型将与消息传递类交互。不需要其他数据格式，除非您没有告诉我们某些要求。

于 2013-09-05T13:39:57.203 回答
0

我的问题是 UI 层是否需要担心它的请求 XML 是否与实际请求部分相似？UI层可以直接将JSON格式的数据发送给按摩类，按摩类将其转换为实际的请求xml吗？

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

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

或者换句话说，问问自己实施新格式的目的是什么，以及所有额外的编码和“按摩”对性能的影响。

除非还有其他事情你没有告诉我们，否则这一切对我来说听起来有点不必要。

于 2013-09-05T13:38:02.267 回答
0

想想服务！服务器提供和客户端使用的任何功能都应该由服务接口抽象出来，这样使用该服务的代码就不必担心它的实现或涉及的任何协议。然后，您可以在服务器上拥有实际的实现，以及客户端的远程外观实现，它将请求转发到服务器并处理响应：

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
}

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

如果您使用标准化的RPC（远程过程调用）协议（例如 SOAP 或JSON-RPC），最优雅的处理方式是使用Proxy以通用方式InvocationHandler进行请求编组和响应解组，允许您廉价地创建远程服务代理。

于 2013-09-05T13:38:39.923 回答