I've had a number of people commenting or sending emails with a statement like this:
I was reading your blog and also looked into the caliburn homepage and I was wondering how this project compares/relates to PRISM. Is it the same kind of problems that are targeted? We are about to start looking more into PRISM for our new development project and found this information about Caliburn very interesting.
In short, Caliburn is geared towards solving many of the same types of problems that Prism does. Prism's primary focus is on Composite Applications. Caliburn covers these scenarios, but also has a number of features designed to make general WPF development easier - regardless of the size or complexity of the project you are building.
Caliburn has at least a year's head start on Prism and is a fully-baked reusable framework, whereas Prism is presently only available as a reference implementation. You can contrast Prism's origins with the fact that Caliburn's primary features are based on real world struggles I've had building WPF applications and it (earlier versions of it) have already been deployed in the wild. Additionally, I am currently using the latest Caliburn bits to build a product for my company and we also plan to use them on a new WPF project starting in a couple of weeks.
Caliburn is presently in Beta 1. I'm not planning on adding too many additional features before Beta 2 and hopefully zero breaking changes. My goals for Beta 2 are simple:
- To have adequate developer documentation and samples.
- To have a working implementation running on Silverlight Beta 2 with as many features ported as SL will easily allow and that make sense for the platform.
As you can see, my release schedule is somewhat dependent on the Beta 2 release of Silverlight.
I'd like to point out that I am a member of the Prism Advisory Board and am working with the P&P team along with a number of other qualified individuals to insure that Prism is the best it can be. I'm seeking to give practical advice while not forcing the team to make some strange Microsoft clone of Caliburn. That's not easy for me. But I believe that for Prism to be successful, it is important that the team have their own struggles and solve them in their own way, with a gentle nudge from the PAB when necessary.
That said, it's truly interesting how similar some of the solutions the Prism team finds are to Caliburn's implementation. Here's a few examples:
- Both abstract a DI container through an IContainer interface.
- Both enable composite views. Prism through IRegion and Caliburn through IComposite.
- Both favor the Model/View/Presenter pattern with additional use of Presentation Model (aka MVVM for those of you who have been reading Gossman or Crevier).
- Both are seeking to make async code easier to write.
- Both enable modular application architectures and I have an IModule interface.
- Both have a strong emphasis on Testability and Plugability.
There are many other similarities and I can't deny that seeing the Prism team come to many of the same conclusions as me makes me feel good about my contribution. Indeed, the Prism team should feel pretty well justified in their solution as well - unless all of us are crazy, of course.
So, in short, Caliburn and Prism are very similar. Of course I'm partial to my own creation, but I'm hopeful about what Microsoft is working on. Since both frameworks are so componentized and pluggable, there is, in fact, no reason why you can't use them in tandem. If you like Caliburn's Action Messages (and related goodies) but prefer the IRegion implementation of Prism over Caliburn's IComponent, why not use both?
04-28-2008 4:55 PM