Composite Application Guidance (CAG) for WPF is here!

Patterns and Practices just released the Composite Application Guidance (CAG) for WPF 2008.

You might know it by its codename, "Prism" ... a name I loved and will miss. What matters is that it exists. There is now a set of libraries and guidance for building WPF applications in a compositional manner.

Why does this matter? Because most of us have learned the hard way that we should "compose" our applications from parts and pieces. The question is not should we do so, but how to do so.

How do we build those parts independently and make them come together in what the user perceives as a single application? It's easy if the parts have nothing to do with each other. It's much harder if the parts must interact. We're going to need some architecture, some patterns, and some glue code to achieve that blissful state in which truly independent components, with no references to each other, somehow manage to collaborate seamlessly.

Patterns and Practices has been down this road before with the Composite UI Application Block (CAB) and its add-ons (Smart Client Software Factory, Web Client Software Factory, etc.). CAB was PnP's pioneering effort in this space. It achieved considerable success; there were many substantial applications built with CAB and my company wrote its own application integration layer on top of it called Cabana.

It also acquired substantial notoriety. Everyone agrees it had too many moving pieces that were hopelessly entangled and that it was devilishly difficult to learn.

So when the team took up the challenge of providing compositional guidance for WPF applications, they seized the opportunity to re-examine the CAB experience, harvest what worked, and improve upon its defects.

They reached out to the developer community, drawing upon those with CAB experience and upon those who had experience with rival approaches. And they listened. And they spiked what they heard and listened some more. They turned the spikes into production code and listened again. Iteration after iteration.

The Results

They have delivered an elegant product. On time. Far ahead of the December '08 date that I dreamed of in my unbridled optimism.

I think it hits the right notes. CAG is small enough to understand and rich enough to support serious application scenarios. The parts work well together. But you don't have to use them all and you can easily substitute your service for any of the shipped services.

The team likes to talk about how you can replace the Dependency Injection mechanism with your favorite: Unity, Castle, StructureMap, etc. I think it is as important that you can replace the EventAggregator or RegionManager or any other ingredient that didn't suit your needs. Not that I'm in a hurry to do so. I just want the comfort of knowing that I could.

This time PnP devoted serious effort and resources to guidance. You see it most prominently in the "Stock Trader Reference Implementation" (RI) that demonstrates (a) what we mean by a "compositional UI" and (b) how all of CAG collectively supports such an application. It is simple without being simple-minded. It's a toy for sure but it serves its pedagogical purpose well.

Note: Please don't build on it! It is not an application framework. Its practices are not always the "best" or even necessarily good. It is a resource for you; a place to discover how you might solve a problem with two or more CAG components in combination.

I don't know for sure but it sure strikes me that CAB's RI, the "Bank Teller", was an afterthought. Not so with CAG's "Stock Trader". It was designed first, before CAG work began in earnest. It co-evolved with CAG. It is and was intended to be CAG's "acceptance test".

There are eight "Quick Starts" that explore CAG components individually and (mostly) in isolation. As with the RI, you wouldn't slavishly adopt Quick Start code. Indeed, you should probably fight with this code, hurl it against the wall, and shake your fist ... and after your satisfying tantrum subsides, you will realize that you understand how it works. Somewhere, someone on the PnP team will be smiling.

There are over 300 pages of CAG documentation. This is not of the "insert tab 'A' into slot 'B'" variety. The team tried to explain "why" as well as "how" and it shows.

Is CAG right for you?

How would I know? I haven't built anything with it yet. And I don't know anything about you. That won't stop me from telling you what to do.

I would use CAG if I was starting a new WPF project. I'm convinced it will pay dividends immediately. WPF applications, more than Windows Forms applications, resist compositional strategies. I'd want to work on manageability early. WPF itself is still a struggle to learn and when things go wrong, they go really wrong. I want confidence that if this little corner of the application catches fire, the rest of my house is well insulated and will keep standing.

There is no CAG for Windows Forms or Web Client. If I had an existing CAB investment, I'd stay with it. If you are starting a new Windows Forms project and have some time to kill, you might glom on to one of the efforts to port CAG to WinForms ... there is sure to be someone attempting it soon. I say this as a CAB guy too. I would be sorely tempted to develop in CAG rather than CAB if I was starting a new WinForms app and had enough lee-way to make some beginner mistakes. It's simply that much better than CAB, even in the medium term.

If you have a CAB app today, do not despair. Don't be distracted. Don't drop everything and re-implement in CAG. CAB is working for you. Sit this one out until there is more real world CAG experience.

If you're building your application in Silverlight ... you're getting ahead of yourself aren't you.  Expect to see a CAG for Silverlight. Someone is bound to port it. I just don't know who.