views:

360

answers:

4

I am creating a card game in C# for a school project. This card game is networked. The card game's game data is stored in a singleton object as gameData. gameData holds, the player names, which player the game is waiting on, player objects. Each player has 3 List objects. Where the cards are again custom objects. Originally I was going to create a ToByte() method for each card, player, and gameData object and serialize them to send over the network using TCPlistener. However running low on time I am looking for other ways.

These are the solutions I have heard of:

-SOAP (Have no clue how to implement this)

-Database (seems overkill for LAN, unless if a small database server can be made to run on the fly)

-Client Activated Object (but this create different singleton for each client)

What I would like to do is make that each client use their own gameData but using the get, set it would talk to a server that host this singleton object data. What do you recommend?

+1  A: 

Since this is a school project, I think using .NET remoting is the fastest way to go :)

To make things simple and reduce nasty debugging and object management stuff, I would suggest handling everything on the server using a singleton object and return marshal by value objects to clients as data (again, since it's a school project). Give each client an ID to pass to the server object.

Mehrdad Afshari
Do you have a tutorial for remoting objects somewhere?
kthakore
A: 

.net remoting is more or less built for the sort of thing you're asking, but not necessarily what you need.

Any remote access to a class is going to leave you with a "singleton" on the other end of the wire really isn't a singleton at all, but a proxy stub in local memory.

In your situation, I would add a service class (possible web service) that accepts in-bound requests and applies them to the singleton on the server side, then returns the required data. This will save you a world of debugging pain.

Jekke
A: 

I would avoid the singleton completely. Not only does is it a pain for remoting, but is often considered a bad design pattern anyway. There are lots of discussions here on SO as well as around the web about why singleton is bad. I think, especially in this situation, if singleton is going to give you a problem, avoid it.

[Edit] One of the main motivations for avoiding singleton is that singleton provides a shared, global state, which is the enemy of unit testing. Avoid it whenever possible.

Matt Olenik
+1, would give +2 (if it was possible) if you could explain some alternatives. The problem is that "Singleton" gets chosen as a default solution too often. What pattern would you use to solve the shared state problem?
Michael Meadows
+4  A: 

WCF supports singleton services

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)] 
class MySingleton : ...
{...}

This way you have one single service instance that serves all of your clients.

WCF makes it easy to do network communication with very little network code.

Check out this article for more details.

Combine the singleton instance with any WCF tutorial you find, and you should have a good starting point.

Good luck.

TJB
Thanks for an awesome reply. I learned alot fro WCF.
kthakore
Glad to hear! WCF is the way to go for networked applications and inter-process communication. If this did it for you, go ahead and mark it as the answer ;)
TJB
Ya I would have used this but I am trying out remoting. Thus I am leaving this open until I have decided between this.
kthakore