... or rather, a complete lack of WCF Duplex Services because they're more complex than they would appear. 

I was looking for a project to start with Prism and needed something that had a good separation of modules to use as a test project.  I decided on a multiplayer Mancala game, since Joshua (my 7 year old) and I have fun playing it and it would be a cool computer-y thing we could do together.  I thought that having a sidebar to chat in while we play would be nice, and maybe later I could add voice chat functions too.  The game itself is pretty simple, but I've decided to add a little complexity into the implementation by setting both boards with the player's side down.  This means that I can't just push the same UI to both clients and so I'm forced to abstract the actual game away from the visual representation of it.  Which is a good thing.  In any case, I got as far as making some basic classes to represent the game and the players and figured I would write a service that would handle both the game moves and the chat.

WCF Duplex services is really the way to go here.  I suppose this might be possible using sockets, but I have a feeling that I couldn't really make that user-friendly without a LOT of work (and I don't see asking a 7 year old to punch a hole in his firewall as going very well).  But a duplex service should be able to handle the two way traffic just fine and in a non-threatening way.  I figured that I could just fire up the MSDN documentation and have at it.

No way.  In the end, the documentation suffers from either over explaining how many different ways there are to do everything or providing no explanation at all for what I'm trying to do.  There seem to be at least 5 namespaces involved and, it first appeared, heavy use of both attributes and overrides of base functions.  Neither of these things scare me specifically, but it means that I have to dig deep into the base classes to see exactly what I'm overriding or what exactly consumes the attributes that I'm writing and my goal here really isn't just to get this one project done, but to learn something in the process.  So most of my coding time today was really spent reading docs and trying to find a good example project.

I managed to find a good example, which I'll chew on over the next couple of days, over at Coding4Fun, which has some other great projects that I've learned a lot from in the past.  Giovanni Montrone wrote an article on developing a file transfer application in Silverlight 3, something I've wished for in the past when chatting with friends whose IM capabilities are less than stellar.  It supports basic chat and file uploading, which should be close enough to adapt for my purposes.  As I type this, I'm thinking that it might be something that I could turn into a general purpose library for Kongregate-style Silverlight games.  Either way, I think the process of burning through links and documentation was worthwhile, even if at the end of the day I still can't tell you exactly how this stuff works.  It's going to make for a good project to learn Prism, Unity, and WCF, and probably a good chance to practice a lot of refactoring.  More to come...

Let me begin by saying that Prism does not strike me as being easy stuff.  Maybe it's not supposed to be, but there's nothing here that seems to make it any easier.  The fact that the instructions begin with hunting down the projects, building it (couldn't I just pull the dlls directly?) and then adding a number of references that I can't say that I fully grok.  Part of the problem is likely that I'm actually exploring the MVVM pattern and the Unity IOC container at the same time, but there's a lot here for what seems like a simple, but very significant gain.  The significant part excites me.  I don't think it's just a testing thing either; the notion of being able to write modules in a complete but separate way and then attach them to my application appeals to me for my current project specifically.  I think it's less about making some kind of custom version for different people (neat idea, but not something that I need) and more about separating the project into parts that are easier to digest.  My prototype, limited as it was, still got way too long and complicated and was difficult to follow by the end.  Breaking things down into smaller files just meant that I had to have all the files open in order to follow it.  By separating things into modules, I am certain that each module is self-contained and so, if I can't understand it, the problem is with that module, not the whole program.  I acknowledge that I may look at this later and decide that I don't really get the advantage the Prism gives me.  That's ok; I'm happy with the value I see in it now and that should let me go further.

So here's the flow as I understand it.  Assuming I have some data object that I want to use, I need a service that returns that object (or a collection of said objects) and an explicitly defined interface for that service.  The interface part seems the most unfamiliar to me, though I don't do a lot of testing/mocking of simple objects like this and I really do see the value in defining things this way (being able to swap out the real service for a mock one so you can test it).

The View Model is where it gets fuzzier for me.  It might be because Silverlight doesn't have a notion of Commands (WPF does) and so I've gotten used to programming without them, which unfortunately means that you're either writing the implementation of a command into the code behind itself or you're creating a hard link between the implementation and the actual UI Event.  What gets me is that the View Model is still pretty View specific; I don't see (yet?) how I could write some kind of generic View that could might work for different View Models.  Maybe that's something I'll get to later.  Still, I get the flow of it.

The magic seems to be in the module class itself.  This provides a concrete link between the data access service interface and the data access service object (this is where I would swap them out for testing).  It also registers a region (an empty space inside the main visual tree) as containing this specific view.  The first seems to be the Unity side of things, while the second is definitely the Prism side.  Even if I were to get sloppy with the IOC side, I think the notion of creating regions and filling them with module Views makes sense.

The shell then needs to have a catalog of modules (I added it with a direct reference, but I can see how you might set up some kind of watcher on a directory and then load the assemblies and add them dynamically).  In this case it's created in the bootstrapper (part of Unity) and the entry point for the application looks like it moves from App.Run() to Bootstrapper.CreateShell() and Bootstrapper.GetModuleCatalog().  I'm still looking into how modules will talk to each other, but I can see how to create a tray full of widgets and how one might swap widgets in and out dynamically.  There's certainly more; I'll keep exploring the framework and expand on this when I figure it out.

I did write code for this, by the way.  I went through Erik Mork's excellent video and made some small tweaks to what he walked through.  I really get a lot of value out of typing things in myself, even if the only changes I were to make were just changing the names of a variable or two.  There's some kind of 'coding muscle memory' that goes along with actually having to create the classes, add the references, add any using statements, and actually write out the code.  I wouldn't say that going through it once means I'll remember it, but it's far better than just reading the code.  The only reason I'm not posting it here is because the description goes a lot further than the actual code does.  A good exercise overall.