所有层级的界面相同
我正在开发一个具有一个主服务器和多个使用 JMS 进行通信的客户端的系统。
服务器是用 Java 编写的三层应用程序。在服务器的数据访问层中,我发送带有一个队列上的任务的 JMS 消息,并从另一个 JMS 队列上的客户端接收任务状态消息。从这些状态消息中我基本上只提取字符串。
我选择了三层架构,因为我还需要访问数据库并执行其他与业务相关的计算,然后才能将任务发送给客户端。
我希望状态消息的字符串通过所有层传递到显示它们的 GUI。
我的想法是对字符串经过的所有层类使用相同的接口,以强制它们都具有相同的接收数据的方法。
另一种方法是为图层类提供单独的接口,但除了具有不同的类名之外,这些接口本质上是相同的。
哪种替代方案是确保各层之间干净通信的正确方法?
I am working on a system with one master and multiple clients that communicate using JMS.
The server is a three tier application written in Java. In the server's data access layer, I am sending out JMS messages with tasks on one queue and I am receiving task status messages from the clients on another JMS queue. From those status messages I basically only extract Strings.
I have chosen a three tier architecture because I also need to access databases and do other business related computations before I can send a task to the clients.
I want the Strings of the status messages to be handed through all layers to the GUI where they are displayed.
I had the idead to use the same interface for all layer classes where the Strings go through, to enforce that they all have the same methods for receiving the data.
The alternative would be having separate interfaces for the layer classes, but those would then be essentially the same, except having a different class name.
Which alternative would be the proper way to ensure clean communication between the layers?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我认为你所说的“穿过层的字符串”是某种人类可读的、有意义的消息,如果你认为在 GUI 中显示它有意义的话。
我肯定会推荐围绕这些字符串创建一个简单的值对象,即而
不是传递原始字符串。原始字符串意味着每一层都必须知道如何处理它们(如果需要);值对象隐藏了复杂性。此类值对象可以存在于所有层中,就像 JPA 实体一样。
如果需要,您可以管理
StatusMessage
的生命周期,方法是确定它只能由 JMS 消息的 DA 层创建并使其不可变,以便您确保它在传输过程中不发生变化。各层。您还可以在各层之间划分与StatusMessage
相关的功能:希望我正确地理解了你的意图。
I presume what you call "strings going through layers" are some sort of human-readable, meaningful messages, if it makes sense to you to display it in the GUI.
Making a simple value object around these strings is what I would certainly recommend, i.e.
instead of passing raw strings around. Raw strings would mean each layer having to know how to handle them, if ever needed; a value object hides the complexity. Such value objects can live in all layers, in a similar way JPA entities can.
If you need to, you can manage the lifecycle of
StatusMessage
by deciding it can be created only by the DA layer our of your JMS message and making it immutable, so that you're sure it travels unchanged through the layers. You can also divide functions related to theStatusMessage
among the layers:Hope I interpreted your intentions correctly.
我假设这是一个伪同步响应(您在某种程度上有来自不同队列的相关请求/响应,或者在响应队列上使用了某种轮询机制将事物连接在一起)。否则我不明白响应如何从 JMS 队列向后流动到 UI 层。
对于您的实际问题,如果预先知道可能的状态消息(字符串)列表,为什么不将从队列接收到的字符串消息转换为状态枚举。这可以作为对其他层的响应传递(可以包装在值对象中)。这将使您更好地控制希望在 UI 上显示的内容,并帮助您更好地管理相关业务逻辑(例如,假设您希望根据收到的状态提供不同的业务处理)。
I am assuming that this is a psuedo-synchronous response (You have somehow co-related request/response from different queues OR used some polling mechanism on response queue to tie things together). Otherwise I don't understand how response can flow backwards from a JMS queue to the UI layer.
To your actual question, if list of possible status messages (Strings) is known upfront, why don't you convert String message recieved from queue to a Status enumeration. This could be passed as response to the other layers (may be wrapped within a Value Object). This would give you better control on what you wish to show on UI as well as help you manage related business logic better (e.g. say you want to provide different business treatment based on Status recieved).
人们在编程时应该始终牢记后续的变化。如果为所有三层保留一个接口,那么如果其中一层或两层由于某种原因需要更改,会发生什么情况。您最终会更改所有三层的类。想象一下,如果对 UI 上显示的字符数量施加限制,会发生什么?或者更改 UI 上的编码?
最小化变化及其影响是所有设计的最终目标。
One should always program keeping in mind changes down the line. If you keep one interface for all three layers, what happens if one or the two of the layer needs to change for some reason. You end up changing classes at all three layers. Imagine what happens if you impose a limit on number of characters to be displayed on the UI? or change encoding on the UI?
Minimizing change and its impact is the ultimate goal of all designs.
您所解释的场景不足以决定您项目的界面设计。不加区别地使用重复的接口,而实现这些接口的类中几乎没有或根本没有行为,这不是一个好的设计。
真的需要严格的层分离吗?
您想让不同的 GUI 访问您的业务层吗?
操作都是只读的?
你的系统有多大?
最后,“干净的沟通”对于做出关键的架构决策来说非常模糊。如有疑问,请使解决方案尽可能简单,并在必要时进行重构。
The scenario you explained is insufficient to decide about the interface design of your project. The indiscriminate use of repetitive interfaces, with little or no behavior in classes that implement them, is not good design.
Is there really a need for a strict separation of layers?
You want to have different GUIs accessing your business layer?
The operations are all read-only?
How big is your system?
Finally, "clean communication" is very vague to make critical architectural decisions. When in doubt keep the solution as simple as possible and refactor if necessary.
由于缺乏相关信息,不太明白您的问题是什么,但以防万一它有帮助,请查找 java.lang.reflect.Proxy.getProxyClass()。
为什么决定将应用程序分成 3 层,这只会在层层次结构中上下路由呼叫?
如果您的目标是将视图与 jms 源分开,我认为最好创建一个 JMS 实现工厂,其接口将在视图层中使用。
在您描述的情况下,我不认为有任何理由添加业务层。
Not quite understood what your problem is because of a lack of information on it, but just in case if it helps, look for java.lang.reflect.Proxy.getProxyClass().
Why it is decided to break application onto 3 tiers, which will just route calls upside and down the tier hierrachy?
If your goal is to separate view from jms source, I think it would be better to create a factory of JMS implementations, whose interfaces will be used in view tier.
I don't see any reason for adding business layer in the situation you described.