Over the next few weeks I will be publishing a series of posts explaining the open source Jounce project that I just released. Jounce provides guidance for building modular Silverlight applications using the Managed Extensibility Framework (MEF) and Model-View-ViewModel (MVVM).
Origins
I have been building enterprise Silverlight applications since late in the version 2.0 cycle. Many of these applications require extensibility: making it easy to add new screens or modules. The applications often require modularity as well, specifically to allow for dynamic loading of assemblies to reduce the initial memory footprint and impact on the client browser.
In addition, after trying Model-View-Controller (MVC) and experimenting with MVVM, I quickly found MVVM to be the right tool for my job. My background of developing mission critical applications for over a decade had already imposed the discipline of creating decoupled solutions that are easy to unit test and build in parallel to scale across large development teams. After exploring homegrown factory methods, Unity, and other patterns, I found that MEF really addressed most of my Silverlight needs out of the box.
The end result is that I've been using a common set of patterns across multiple applications. Developers know and understand the value of tools and macros. We're wasting our customers' time if and when we build something from scratch that has already been addressed, and this is why I constantly found myself sharing base classes, interfaces, and other core structures across various projects. I kept this basic framework factored separately to seed new projects and added to it as I encountered new challenges.
This framework is what I recently packaged as Jounce. It is similar to many MVVM frameworks because it provides messaging services and notify property changed handlers. It is different beacuse it does not attempt to abstract the underlying inversion of control - make no mistake: Jounce has a direct, explicit dependency on the Managed Extensibility Framework.
Why Should I Use Jounce?
I've been wanting to share Jounce for quite awhile but resisted because the last thing we need is "yet another framework." I was asked that exact question when I decided that all of my blog posts and examples just don't make as much sense without the context of the underlying framework they derive from.
The answer to the question is a simple one. "Don't."
I'm not trying to compete with the many other mature frameworks that are there. I like all of them. So why Jounce? I released Jounce less as a framework to package and solve all problems, and more as guidance for how I've found MEF can help solve MVVM problems in the Silverlight domain. It's a very specific niche, and I'm not trying to cover both Silverlight and WPF and the Windows Phone 7, nor abstract the notion of dependency injection containers. This is a very specific set of principles that I've used to successfully resolve challenges in a specific space.
The idea here is that you can pull down the source for a framework that is extremely lightweight - less than 1,000 lines of code. That's something you can dig into and look at inside and out. The license for Jounce allows you to use it right out of the box if you like, but my guess is that most people have far more specific needs for their framework than any package can provide "out of the box." For this reason, you are welcome to customize and modify Jounce or use the pieces that make sense for your project and toss the rest out.
Jounce is far more lightweight than Prism is and addresses fewer concerns. The Jounce implementation of the region management pattern takes only a few lines of code and isn't quite as powerful as Prism is ... but I've seldom needed that extra power. Jounce does not have automatic convention-based data-binding that Calburn and Caliburn.Micro provide, but again, I've found I prefer to use explicit data binding and design-time view models with a focus designer-developer workflow.
I've tried to note where a portion of Jounce was derived from another framework, both to give due credit and also to give you a place to explore further.
Some of the guiding principles behind Jounce:
- Code in
App.xaml.csis extra noise we don't need. Use the more elegant IApplicationService instead. - Tracing is important even if Silverlight doesn't provide native trace support
- Commands should be wickedly easy to wire up and use whenever/wherever you need them
- Let me compose messages on the fly and consume them whenever I want (and not have to worry about marshalling them to the UI thread)
- When raising property changed events, magic strings make refactoring a pain so do it strongly-typed instead
- View models synchronize view state, so they should be aware of view state changes and be able to set visual states without refrences to the view
- Tagging a view model should be both flexible and trivial
- Tagging a view should be just as easy
- We don't need a huge ceremony to bind a view to a view model, why not just say this view goes with that view model and be done with it?
- Let's face it: view models talk, so let's make it easy for them to find each other
- If I am navigating to a view, I shouldn't have to worry about whether it is in a separate, dynamically loaded XAP file
- Navigation should be a simple event, and swapping/transitioning/etc are just implementation details
- Having a bunch of asynchronous processes fire sequentially shouldn't require a dozen methods or lambda expressions nested so deep I need three monitors to read them all
How do I Get Started?
The full source code for Jounce is available at Codeplex. You can pull it down, compile, and get started. The framework has a web project with a simple view and view model. There are several quick starts that demonstrate navigation, regions, dynamic XAP loading, and more ... and I plan on adding others for the 1.0 release.
The power of Jounce I believe comes from the experience of using it. None of the quick starts took very long for me to create with no or minimal troubleshooting to make a feature work. That in my mind is the ideal goal of a framework: to be lightweight and easy to use, and easy to troubleshoot when things go sour. I believe Jounce exhibits all of this.
So in conclusion, Jounce is not the "next hot framework" that I'm begging you to download and use. I don't intend to come out with super cool feature-packed releases ... but if I find a better way to solve a problem or a new idea that pops up often, I will look at including that in the future.
In the next posts I'll start drilling into the details of how Jounce works. Much of this will be familiar to long time readers of my blog, with the difference that the ideas are encapsulated in a full reference framework rather than parceled into small "sample project" chunks.
Your feedback and suggestions are more than welcome!
