Silverlight Map Control module design approaches

Topics: Prism v2 - Silverlight 2, Prism v2 - WPF 3.5
Jul 14, 2009 at 7:40 PM

Just looking to see if anybody has any samples using the Silverlight Bing Map Control with Prism and how they approached their design.

I am planning on creating a MapModule that puts the map as one of several Views on a region on the Shell.  I then want to be able to load other modules as needed and have them add layers to the map.  (I am already able to create and display the map in a module without much trouble.  Neat stuff!)

The other loaded modules would have control panels that they expose in other shell or module regions.  They would have points of interest that they would want to show on the map.  They would want to show and hide the points as needed based upon whatever criteria they come up with.  What "other" modules are loaded would be decided at run time.

I have previously done this in SCSF and Cab with the VE Web Services and my own Mapping Smart Part ( the view ), but wanted to change the MVP paradigm a bit and see what I could come up with for Silverlight and CAL.  In SCSF I create a service that the other modules load via DI. The service surfaced an AddLayer and AddItem ( among other ) functionality.  The service would then publish an event that the Mapping smart part's presenter would subscribe to.  The smart part would then get the new layer/items and put them onto the map.  The other modules didnt know about the details of the map, only the service interface.  It worked well, for what it was.  The Mapping smart part didnt know about new modules, and all the new modules knew about was the service interface.

I am not looking for the group to provide a complete solution, just some fresh ideas on how others would approach this.  I want as little coupling as possible, but as much MVVM usage as I can get.  If push came to shove, I would want to be able to replace the mapping module with a different implementation if needed, without major surgery on any of the "other" modules.  And the reverse is true.  The Map Module should know nothing about the "other" modules loaded.  The Map Module will not be the only view on the shell, so the Shell should be ignorant of what is on its surface . 

There are lots of CAL organizational questions to ask, like:

While using MVVM, how do I make sure that the loaded modules' DataTemplates are visible to the Map Control module when it goes to add an item.   Should I add them to the applications resource dictionary?  How do I isolate the loaded DataTemplates from knowledge of the Map Control specifics? 

Is the ModuleInterface project and Module project "pattern" that was used so heavily in early SCSF a good organizational pattern to use in a CAL project to reduce the coupling between implementations of the modules.  I.E.  define the service interface in a ModuleInterface project, reference that project in "Other" module projects, and then put the implementation of the service in the Module project, which nobody but the Bootstrapper knows about.

So, any ideas or approaches?  I want to get out of the CAB/SCSF mindset where appropriate.

Thanks in advance.