Question

我正在使用一个主服务器和多个客户端使用JMS进行通信。

服务器是用Java编写的三层应用程序。在服务器的数据访问层中，我发送带有任务的JMS消息在一个队列上，我从另一个JMS队列上的客户端接收任务状态消息。从这些状态消息中我基本上只提取字符串。

我选择了三层体系结构，因为在将任务发送给客户端之前，我还需要访问数据库并进行其他与业务相关的计算。

我希望状态消息的字符串能够通过所有图层传递到显示它们的GUI。

我让idead对Strings经历的所有图层类使用相同的接口，以强制它们都有相同的接收数据的方法。

替代方法是为图层类提供单独的接口，但除了具有不同的类名外，这些接口基本相同。

哪种替代方案是确保各层之间清洁通信的正确方法？

Answer 1

我认为你所谓的“通过图层的字符串”是某种人类可读的，有意义的消息，如果你在GUI中显示它是有意义的。

围绕这些字符串创建一个简单的值对象是我当然会推荐的，即

public interface StatusMessage {
    String getContent();
    void setContent(String content);
    // ...
}

public class StatusMessageImpl implements StatusMessage { ... }

而不是传递原始字符串。原始字符串意味着每个层必须知道如何处理它们，如果需要的话;值对象隐藏了复杂性。这些价值对象可以生活在所有层中，与JPA实体类似。

如果需要，您可以通过决定只能通过JMS消息的DA层创建它并使其不可变来管理StatusMessage的生命周期，这样您就可以确保它通过层。您还可以在图层中划分与StatusMessage相关的功能：

DAL知道如何从JMS创建StatusMessage，或者如何将其打包回来，
BL有使用StatusMessage的例程（业务对象？），
GUI组格式化和显示功能。

希望我能正确理解你的意图。

Answer 2

我假设这是一个伪同步响应（你有某种与来自不同队列的共同相关的请求/响应，或者在响应队列上使用了一些轮询机制来将事物联系在一起）。否则我不明白响应如何从JMS队列向后流到UI层。

对于您的实际问题，如果预先知道可能的状态消息（字符串）列表，为什么不将从队列接收的字符串消息转换为状态枚举。这可以作为对其他层的响应传递（可以包含在值对象中）。这样可以更好地控制您希望在UI上显示的内容，并帮助您更好地管理相关的业务逻辑（例如，假设您希望根据收到的状态提供不同的业务处理）。

Answer 3

人们应该始终记住改变方向。如果为所有三个层保留一个接口，如果某个层中的一个或两个由于某种原因需要更改，会发生什么。您最终会更改所有三个层的类。想象一下，如果对UI上显示的字符数施加限制会发生什么？或者在UI上更改编码？

最大限度地减少变化及其影响是所有设计的最终目标。

Answer 4

您解释的场景不足以决定项目的界面设计。不加选择地使用重复接口，在实现它们的类中很少或没有行为，这不是好的设计。

是否真的需要严格分层？

您希望有不同的GUI访问您的业务层吗？

这些操作都是只读的吗？

你的系统有多大？

最后，“清洁沟通”非常模糊，无法做出关键的架构决策。如果有疑问，保持解决方案尽可能简单，并在必要时进行重构。

Answer 5

由于缺乏相关信息而不太清楚您的问题是什么，但如果有帮助，请查找java.lang.reflect.Proxy.getProxyClass（）。

为什么决定将应用程序分解为3层，这样只会将呼叫上行和下行路由？如果您的目标是将视图与jms源分开，我认为最好创建一个JMS实现工厂，其接口将在视图层中使用。在您描述的情况下，我没有看到任何添加业务层的原因。

所有层的界面相同

5 个答案: