Java:在客户端和servlet之间传递消息的适当方法?

发布于 2024-07-20 02:24:37 字数 262 浏览 10 评论 0原文

我的系统成功地将对象从客户端传递到 servlet。 然而它很原始,因为它是为了迎合 Java 1.1 而构建的。 它传递的消息对象由一个 int (表示大约七十种类型之一)和一个需要解析的令牌字符串(令牌可能包含列表、对象列表等)组成。 不好!

所以,我希望将其重构为 Java 1.5。 使用枚举而不是整数无疑是一种改进,但我不确定如何发送消息的其余部分。 创建七十个不同的类来表示每种类型肯定不是正确的方法。

关于我应该如何重构这个的任何指示?

My system successfully passes objects from a client to servlet. However it is primitive as it was built to cater for Java 1.1. The message object it passes consists of an int (representing one of about seventy types) and a String of tokens which need to be parsed (the tokens may contain a list, a list of objects, etc). Not good!

So, I'm looking to refactor this to Java 1.5. Using an enum instead of an int is certainly an improvement, but I'm unsure how to send the rest of the message. Creating seventy different classes to represent each type surely isn't the correct way to go.

Any pointers on how I should refactor this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

才能让你更想念 2024-07-27 02:24:37

您可能想使用序列化对象。

它们旨在轻松地通过网络传递。

在您的情况下,您只需要一个序列化的“消息”类。 然后您可以读取它并将其写入流。

这里是有关使用序列化对象的教程。 那里有很多。

You may want to use serialized objects.

They are meant to be easily passed along the network.

In your situation you will just need a serialized 'message' class. Then you can read and write it to a stream.

Here is a tutorial on using serialized objects. There are lots out there.

人生戏 2024-07-27 02:24:37

无需创建不同的类来表示每种类型的消息。 您可以使用所需的属性创建一个消息类。 像这样:

public class Message implements Serializable{
     private Long id;
     private String msgText;
     //other necessary properties

     public Message(){
        this(0, "default message");
     }

     public Message(Long id, String msgText){
         setId(id);
         setMsgText(msgText);
         //etc
     }

     //getters and setters
}

然后您根据需要创建对象。 例如:

Message m1 = new Message(9, "The Eagle has landed");
//serialize m1 to server

Message m2 = new Message(27, "The Wren has landed");
//serialize m2 to the server

等等。

There is no need to create a different class to represent each type of message. You create one message class with the properties that you need. Something like this:

public class Message implements Serializable{
     private Long id;
     private String msgText;
     //other necessary properties

     public Message(){
        this(0, "default message");
     }

     public Message(Long id, String msgText){
         setId(id);
         setMsgText(msgText);
         //etc
     }

     //getters and setters
}

And you then create objects as needed. For example:

Message m1 = new Message(9, "The Eagle has landed");
//serialize m1 to server

Message m2 = new Message(27, "The Wren has landed");
//serialize m2 to the server

and so on.

只是偏爱你 2024-07-27 02:24:37

您还可以使用 xStream 将对象序列化为 XML,然后再次返回对象。

You can also serialize the objects to XML and back to objects again using xStream.

霊感 2024-07-27 02:24:37

第一个问题:您为什么觉得需要做出改变? 是否是因为当前系统不支持您计划添加的某些功能? 还是只是为了打扫而进去打扫? 如果是后者,我强烈建议让睡虫继续撒谎。

第二个问题:我假设这是一个小程序。 您会计划使用不同的前端吗? 或者将此服务器公开为通用服务? 如果没有,那么我回到第一个问题。 如果是,那么您几乎肯定希望避免特定于语言的序列化。

如果您计划将其公开为服务,那么遵循一些“标准”服务协议是一个好主意。 REST 可能是最简单的 POST-ing XML 有效负载。 您也可以使用 SOAP,但我一直认为这样做太过分了。

或者,您可以使用标准的 URL 编码的 POST ...这应该比将所有内容包装在 XML 中更容易实现。

First question: why do you feel the need to make changes? Is it because the current system doesn't support some feature that you're planning to add? Or do you just want to go in and clean up for the sake of cleaning? If the latter, I'd strongly suggest leaving sleeping bugs lie.

Second question: I'm assuming this is an applet. Will you ever plan to use a different front end? Or expose this server as a generic service? If no, then I come back to the first question. If yes, then you almost certainly want to keep away from a language-specific serialization.

If you are planning to expose as a service, then following some "standard" service protocol is a good idea. REST is probably the easiest, POST-ing XML payloads. You could also do SOAP, but I've always considered that overkill.

Or, you could go with a standard URL-encoded POST ... which should be easier to implement than wrapping everything in XML.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文