Wherefore art thou, “Composite Application Guidance” ?

Posted on by

Ok, the title is meant to be a little jokey and is with reference to both Shakespeare and to The Gaslight Anthem and that’s quite a mix to start a blog post with Smile

Quite a while ago, I made a set of videos on the PRISM framework which was also known by the earlier catchy title of “Composite Application Guidance”.

Those videos are up on Channel9 and I still get questions on them but I warn any new viewer that they were made in 2009 which was a long time ago and they were made in the context of PRISM V2 and Silverlight so might need some updating for today’s world.

PRISM is a framework for building “composite” apps which I’ll describe in my own words as an app where pieces (e.g. pieces of UI, pieces of underlying service functionality) need to come together in a loosely coupled but structured way so as to reduce coupling between dependent components. The framework is often used by developers who are building “big” applications with lots of moving parts and where those parts are perhaps being developed across organisational or geographical boundaries and so the developers need to take a highly structured architectural approach to avoid chaos.

PRISM is a big framework with a lot of concepts involved and I’ve seen customers have great success with it and I’ve also seen customers get themselves a bit tied up in knots with it before deciding that they didn’t necessarily need all that the framework had to offer.

When I structured those videos I tried to layer them such that I didn’t introduce too many things at once. I tried to build from the ‘ground up’ talking about topics like;

  1. Abstracting implementation via interface.
  2. Injecting implementation by dependency injection (using the Unity container to do so).
  3. Modularity.
  4. Commands.
  5. Loosely coupled events.

and a lot of these topics are relevant to all development and some of them are specifically relevant to client development using the XAML technologies that have been around since 2006 and have surfaced themselves in WPF, Silverlight and now surface themselves again in Windows 8 Store app development and Windows Phone 8 Store app development.

Those technologies align with some of what you’d usually look for in an “Model View ViewModel” (or MVVM) framework and developers sometimes look to PRISM as an MVVM framework and found it more than they needed because it can be used that way but, in my view, it is more than ‘just’ an MVVM framework.

I talk to a lot of developers who are building for Windows 8 and Windows Phone 8 and the topic of “MVVM” and the way in which a XAML-based application should be structured is very much an active one and especially given that some of the framework pieces in (e.g.) Windows 8 XAML based apps make MVVM perhaps a bit more challenging than it was in WPF or Silverlight (e.g. the lack of libraries like the Blend behaviours library means you might have to do more work or look to a framework to do it for you).

Prism in 2013 – for Windows 8 Store Apps

Into this landscape comes a new version of PRISM specifically targeting Windows 8 applications and with some functionality which is portable across both Windows 8 and Windows Phone 8 (hopefully, that portable functionality will grow over time).

Along with that version of PRISM comes a new reference application, the AdventureWorks Shopper app which developers can take as an example of a “correctly” structured, implemented and tested application to help with learning how to structure our own applications to line up with that best practise.

At this point, I’ve not opened up the box too deeply on this new version of PRISM but what I have done is to watch the video over on Channel9 which I can highly recommend. It starts off looking like one those “let’s just chat” videos but quite quickly turns into an exploration of the code of the reference app;

In particular, what I pulled out of the video on first watching was;

  1. Event aggregation support.
  2. ICommand implementation.
  3. Support for navigation that’s not tied into the UI views and so can be used from view model code.
  4. Lifecycle support via suspend/resume for view model code.
  5. Convention based wiring up of views to view models (with the possibility of overriding the convention).
  6. Dependency Injection with/without a container (tested with Unity but abstracted for other containers).
  7. Validation (there’s not too much in the video on this – it would be interesting to know how this works given previous XAML based validation approaches).
  8. Windows 8 settings charm integration.

and I’m sure there’s more – I’ll be spending some time digging in to both the reference application and the framework itself to see if I can pull it apart a little and drill out the constituent pieces…