Messaging: Lots of RemoteServices methods or Unique message builder/interpreter?

Hey guys, I'm using GWT to code a simple multiplayer board game. And while I was coding the question came up to my mind:

At first I though my client could simply communicate with the server via RemoteServices calls, so if a client wanted to connect to a game he could do as follows:

• joinGame (String playerName, String gameName)

And the server implementation would do the necessary processing with the argument's data. In other words, I would have lots of RemoteService methods, one for each type of message in the worst case.

I thought of another way, which would be creating a Message class and sub-classing it as needed. This way, a single remoteService method would be enough:

• sendMessage (Message m)

The messages building and interpreting processing too would be done by specialized classes. Specially the building class could even be put in the gwt-app shared package.

That said, I can't see the benefits of one or another. Thus I'm not sure if I should do one way or another or even another completely different way.

One vs other, who do you think it is better (has more benefits in the 开发者_如何学编程given situation)?

EDIT: A thing I forgot to mention is that one of the factors that made me think of the second (sendMessage) option was that in my application there is a CometServlet that queries game instances to see if there is not sent messages to the client in its own message queue (each client has a message queue).

I prefer the command pattern in this case (something like your sendMessage() concept).

If you have one remote service method that accepts a Command, caching becomes very simple. Batching is also easier to implement in this case. You can also add undo functionality, if that's something you think you may need.

The gwt-dispatch project is a great framework that brings this pattern to GWT.

Messaging takes more programmer time and creates a more obfuscated interface. Using remote service methods is cleaner and faster. If you think there are too many then you can split your service into multiple services. You could have a service for high scores, a service for player records, and a service for the actual game.

The only advantage I can see with messaging is that it could be slightly more portable if you were to move away from a Java RPC environment but that would be a fairly drastic shift.