For anyone who tuned into part 1 of this series, there was an interesting comment from Ben (one of the Telerik MVPs who also shows up quite often with intelligent commentary in a variety of locations) about the idea of using Prism, MVVM, and WCF RIA together in their current state. This actually fell in line with a number of other conversations I have had with developers over the last few weeks and I realized something very important- he's quite right about the state of things.
Much like 7 is the magic number for Windows, 4 is going to be the magic number for Silverlight. With .Net 4/Silverlight 4 we get a number of new goodies to play with, with MEF being at the top of my list for things to explore. Plus, at that point (or soon thereafter) we should hopefully see a full version of WCF RIA Services that addresses some of the quirks in the current implementation. If all these stars align we will soon after that see Prism 4 (David Hill covers the Prism 4/MEF story excellently in this post), which will give a very compelling story for modular development and how all these different pieces tie together into one cohesive story.
All that being said, I'm stubborn so I am going to keep on with the application as described... but with a twist! At the same time I am developing sections of the application with Prism 2, MVVM, and WCF RIA Beta, I'm also going to create a parallel application that demonstrates the same functionality, except with the event-based, code-behind model (and WCF RIA Beta). This way, I can explore both the way 99% of people are developing RIA's (that stat belongs to Ben, but I trust him :D) as well as show how, with the current betas and implementations, you can create the same thing using Prism/MVVM/WCF RIA. This will also create for an interesting look at updating the app to Silverlight 4 down the road and we can examine how much cleaner the planned frameworks will make things versus the approach that needs to be taken with how things are.
So where are we now? Well, as stated I am looking to develop version A of the application using the MVVM pattern. This opens up some interesting questions, since I want to keep everything as disconnected and modular as possible...
- I want this to be modular, but how will they tie together?
- How will I handle communication within the application? There needs to be some way to work between modules.
- How about the UI? I need some process to handle what will be shown and where it will be shown, with the option to swap views as needed for different functionality.
- If I can't use events/code-behind, how will I handle user interaction? Something needs to give me access to commands that I can use to react to UI events.
This laundry list of concerns can either be handled through blood, sweat, and toil, or I can take advantage of one of the many frameworks that exist already to assist with these fundamental questions. My framework of choice is the Composite Application Guidance from the Microsoft Patterns and Practices team, although most of you will know this as Prism:
For what we need here, Prism fits the bill in the following ways:
IRegionManager - handles inserting views into pre-defined regions as well as switching out views
IEventAggregator - handles the publishing and subscribing of events within the application for de-coupled communication
CompositePresentationEvent - works with the event aggregator, these allow me to send info back and forth between modules
IUnityContainer - our bucket of goodies that holds references to go between the application
As this series unfolds, we're going to see how these different elements all play an important role in solving the MVVM challenges I listed above. Beyond that, we're going to see how they compare to the event/code-behind approach and what it takes to get the same functionality in our applications. Of course, both of these are going to be done using the Telerik RadControls for Silverlight, so you can see that whichever way you are leaning in your development, Telerik has you covered with our high performance and feature rich controls.
Next stop, putting things together and creating our shell/module infrastructure as well as the setup for the code-behind application.