views:

408

answers:

2

I'm working on a 4-player network game in WPF and learning WCF in the process. So far, to handle the network communication, I've followed the advice from the YeahTrivia game on Coding4Fun game: I use a dualHttpBinding, and have use a CallbackContract interface to send back messages to clients. It works pretty well.

However, my service is getting very large. It has methods/callbacks to handle the game itself, but also the chat system, the login/registration process, the matchmaking, the roster/player info, etc. Both the server and client are becoming hard to maintain because everything is tied into a single interface. On the client for example, I have to redirect the callbacks to either the game page, the lobby page, etc, and I find that very tedious. I'd prefer being able to handle the game callbacks on the game page, the chat callbacks on the chat window, etc.

So what's the best way to handle that? I've thought of many things, but not sure which is best: splitting the service into multiple ones, having multiple "endpoints" on my service, or is there other tricks to implement a service partially where appropriate?

Thanks

+3  A: 

You should have multiple components, each of which should be limited to one responsibility - not necessarily one method, but handling the state for one of the objects you're dealing with. When you have everything all in one service then your service is incredibly coupled to itself. Optimally, each component should be as independent as possible.

I'd say start with splitting it up where it makes sense and things should be MUCH more manageable.

Terry Donaghe
I'm a bit noobish with WCF, how can I accomplish that? I'm not sure how I can split my service into multiple components.
Anthony Brien
Just split your service contract interface into multiple new service contract interface. If you're not using an interface as your service contract, then I suggest you look at your method signatures and create new interfaces for each collection you want to split out. Make each of those interfaces a service contract. Make sense?
Terry Donaghe
Thanks, I'll try that. I wasn't sure splitting the contract and having multiple end points was the way to go, because all the samples I found on multiple end points seemed to say its to provide different kind of bindings (tcp, http, ...) for the same contract.
Anthony Brien
Anthony, I strongly suggest you get a copy of "Programming WCF Services" by Juval Lowy. It's a book from O'Reilly and it's pretty much the WCF Bible. It's pretty dense and technical, but it's a treasure trove of all things WCF.
Terry Donaghe
+1  A: 

I would support Terry's response - you should definitely split up your big interface into several smaller ones.

Also, you could possibly isolate certain operations like the registration and/or login process into simpler services - not knowing anything about your game, I think this could well be a simple non-duplex service that e.g. provides a valid "player token" as its output which can then be used by the other services to authenticate the players.

Multiple smaller, leaner interfaces also give you the option to potentially create separate, dedicated front-ends (e.g. in Silverlight or something) that would target / handle just certain parts of the whole system.

Marc

marc_s