Here's a nice pretty diagram of the various components of modelling a (any) world.

In my case here, the world is a virtual world.  You would noticed quickly:

• The strong MVC reference.  If you really don't see it, try look at the colours
• World is made of models - which are actually no different from a business application.  The same model pretty much applies
• SilverLight 2 Beta 2 has strong work done on the visual manager, which I think is best used to utilize for rendering the world
• In fact, in most games, the graphics component is the main component, in my little model here, it isn't.
• The command logic is largely work from WPF's command syntax - in a business application, this means we can wire up multiple events to the same command (aka, control-C, menu)
• In the context of a game, it means we can offer key-bindings and the user can choose what keys he'd rather use instead of the defaults
• The blue part is the least ironed out section of my little model here - in a pure MVC situation, perhaps the Commands should be responsible for directly making the calls to the server / modifying the game objects.
• Should I wait for server response before making the object move?  or should I trust the client and let it start moving, and allow the server to 'validate' the client's behaviour

One final work remains in this modelling exercise:

• Some sort of dependency-injection for making it all work in SilverLight, this way, I can work on each component one at a time and have them plug in/out
• And unit-test separately
• There's some good work in the AssemblyPart class
• Not sure about security implications though