.NET & Funky Fresh



  • <script type="text/javascript" src="http://ws.amazon.com/widgets/q?ServiceVersion=20070822&amp;MarketPlace=US&amp;ID=V20070822/US/bluspiconinc-20/8001/8b68bf4b-6724-40e7-99a5-a6decf6d8648"> </script>
Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Prism and Caliburn's Future

First I'd like to say that I'm stoked about the work the Prism team has been doing.  I have to admit that when they started out in January to deliver a set of guidance for building composite WPF applications, I was skeptical.   But they have come a great distance and I am truly proud to have been able to contribute to the effort as part of the advisory board.  I think their work is a huge success for Microsoft and more importantly to the .Net community at large.  I believe this had a great deal to do with their interaction with the community, their transparency, use of Agile methodologies and tons of unit testing to boot.  I hope this becomes a trend for Microsoft.

With the first release of Prism right around the corner, I've been thinking more about what direction I'd like to go with Caliburn from here on out.  Before I get into that, let me back up and talk a little about how Caliburn came to be...

Several years ago I started playing with WPF, building various little applications, experimenting and generally being impressed with the framework and having a good time as well.  In 2006, the Microsoft Codemaster Challenge came along and CB and I decided to see how far we could take WPF by building an online multiplayer game.  It turned out pretty well (enough to land us in the top 20 out of over 4,400 applicants world-wide) and we learned a lot about WPF in the process.  Unfortunately we were unable to pursue are game development dreams at that time, and were forced into building "real world" applications.  At that time (early 2007) I had begun experimenting more with UI architectures in WPF, originally inspired by Crevier and Gossman's blogs.  There were certain command-related patterns that happened repeatedly when trying to build an MVP style design.  These patterns often resulted in tedious boiler-plate code.  To eliminate this tedium, I created the ancient ancestor of Caliburn's ActionMessage.  I worked on this for a bit, improving it for my own use and eventually wrote this article, describing an early, crude version of the framework.  I worked on this version a bit more and we eventually used it on a real project of ours, a smart client for a large state organization.  Over the coarse of this project I realized a number of shortcomings, improvements and features I wanted to work on.  In late 2007 I began officially working on what is now Caliburn by starting from scratch and building a framework based on a bit more real-work experience.  In the early part of this year, I continued to add features and eventually officially published the framework.

A lot has happened since that time.  Mainly, I've built more WPF applications, been involved with Prism and added tons of features and improvements to Caliburn.  I've found advising Microsoft on Prism and working on Caliburn simultaneously to be a constant struggle.  Some days I hated Microsoft for trying to build what I had already built, other days I was strangely relieved by the thought.  I've found that running my small open-source project is quite challenging (props to the big boys who do it well) and have recently felt the stress mount.

Things changed for me the other day.  I was looking through some of the Prism code in preparation for our regular meeting.  I hadn't looked at it in a while due to the fact that I had to miss several meetings for scheduling conflicts.  I came to their EventAggregator implementation and thought to myself "Dang, that's a really nice implementation."  I looked at it a bit more and realized, "Hey, I like that better than my implementation!"  Well, actually Caliburn has two different implementations that are completely different solutions to the same problem, but I like the Prism solution better than both of mine!  I began to think about refactoring my solution, but then I though "Why couldn't I just use the Prism aggregator in my applications?"

This brings me to Caliburn's future.  Lately I've been feeling that Caliburn has grown rather large and difficult to learn (something I criticized both CAB and Acropolis for).  I haven't had time to fix bugs, document, test, provide an RI, etc. - and I feel like the project has gone out of focus.  Also, when I look at Prism, I see a large overlap in features with Caliburn:

  1. EventAggregator - I actually like the Prism implementation better than mine.
  2. RegionManager - This is virtually identical to Caliburn's CompositionMangaer.  No really, they are practically the same implementation.  (I guess they took some of my advice.)
  3. Module Loading - This is also very similar to Caliburn.

As I have struggled with managing an open source project and wrestled with how to  divide my time between features, bugs, etc.  I've wondered "Wouldn't everything be easier if I just let Prism do what it does best and Caliburn do what it is good at?"  If Caliburn supports a unique set of features, apart from Prism, and could be used as a logical extension to Prism, then I could focus on a smaller set of features, make sure they work well and are consistent, provide ample documentation and samples and actually get some decent test coverage.  (Not to mention reclaim my home life...)

So, I'd like to get some feedback from you.  I have no idea how many of you are using Caliburn our how you would feel about this change in direction.  Please leave me a comment because I don't want to make a decision that is going to seriously cripple anyone.  There are several paths I could take Caliburn and I'd love to hear what you would favor:

  1. Continue development as is.
  2. Shamelessly steel the Prism EventAggregator and replace both my implementations with theirs.
  3. Remove features duplicated in Prism from Caliburn - event aggregation, ui composition and module loading.  Users who want these features can use Prism in combination with Caliburn.
  4. Take a hard dependency on the Prism framework and build on top of it.  This would further reduce duplication and enable the two frameworks to work seamlessly as one.
  5. Scrap Caliburn, but take the unique features (like ActionMessage) and implement them as part of PrismContrib to better flow into the existing community surrounding Prism.

Honestly, I'm leaning towards 3, 4, or 5.  I could easily move through these as a progression, one at the time.  However, I want to be clear that I don't want to cause undue pain for those who are using Caliburn at present, so please leave a comment.  If everyone screams "NO!" then we stick with option 1.  But, the truth is, I really have no idea whether Caliburn has 2 or 200 people who are using it seriously and would love to find out anyway.  Would a future with complimentary features between Caliburn and Prism be meaningful for you?

Posted 06-06-2008 9:24 AM by Rob Eisenberg



Jim wrote re: Prism and Caliburn's Future
on 06-06-2008 10:09 AM
I have been playing with Caliburn to try learning it for an upcoming project that would be perfect for WPF. The lack of documentation has been frustrating, and until the 2 tutorials came out, I was reluctant to use something that I had to dig into source code constantly to figure out feature use. While digging into source provides a good learning experience, sometimes things just have to get done to pay the bills. I think Prism is here to stay. My vote is to take a hard dependency on Prism and build on top of it. Thanks for all the hard work! Caliburn is a great piece of code! jim
Prism and Caliburn's Future - .NET & Funky Fresh wrote Prism and Caliburn's Future - .NET &amp; Funky Fresh
on 06-06-2008 10:14 AM

Pingback from  Prism and Caliburn's Future - .NET &amp; Funky Fresh

Joe wrote re: Prism and Caliburn's Future
on 06-06-2008 11:03 AM
How does PrismContrib work - in the long term? If parts or all of Prism end up in .NET FX 4 (or beyond) then how does that impact the scope of Prism and the IP within it.
Vadim wrote re: Prism and Caliburn's Future
on 06-06-2008 12:00 PM
I would vote for the latter two (why not the last one?)
Rob Eisenberg wrote re: Prism and Caliburn's Future
on 06-06-2008 5:38 PM


Great question.  The answer is that I'm not sure.  I don't think Prism will end up as part of .NET proper any time soon, however.

RobertT wrote re: Prism and Caliburn's Future
on 06-07-2008 10:55 AM
Hi Rob! I've played a little with Caliburn while developing my project and I really liked it. But it was too late to change my directions as I was already using CAB with SCSF and SCSFContrib to build on top of them. And then came Prism. I like it as more guys from p'n'p group work and drop pieces of code. I think you should move Caliburn to PrismContrib project or build on top of Prism. But I like the first one better. Best regards, Robert
Michael wrote re: Prism and Caliburn's Future
on 06-07-2008 2:37 PM
Toss up between 4 and 5
Dew Drop – June 7, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop &ndash; June 7, 2008 | Alvin Ashcraft's Morning Dew
on 06-07-2008 5:02 PM

Pingback from  Dew Drop &ndash; June 7, 2008 | Alvin Ashcraft's Morning Dew

Alex Simkin wrote re: Prism and Caliburn's Future
on 06-09-2008 9:26 AM
I would say 4 or 5
brettryan wrote re: Prism and Caliburn's Future
on 06-09-2008 1:32 PM
Hi Rob, I've only been using Caliburn for less than a week now and Prism (now Composite WPF) off and on since about the second drop so I can't comment too much. Personally, I think that if you take what Caliburn does best and develop these components independantly and not dependant on Prism, then you should be able to use resource injection to get your classes loaded anyway. Isn't this what modular design is all about? So for me it's got to be #3. One thing to note, I would love to see you advise the P&P guys a great deal more.
Darin wrote re: Prism and Caliburn's Future
on 06-10-2008 11:30 AM
I haven't played around with Prism, and only briefly with Caliburn. I like what I've read about Prism, and so far I like what I've seen with Caliburn. Choice is a good thing, I like option 2. If there is enough duplication to not have to reference both Prism and Calburn (although if you needed something from both you still could), that would be nice. If you go for option 5, maybe you could just pass off the project (like to Spring.net)
Glenn Block wrote re: Prism and Caliburn's Future
on 06-10-2008 11:25 PM
I guess i would vote option 6 which is not on the list, but is a hybrid of 5. That is to keep Caliburn going independently, and add the Caliburn-specific implementations where appropriate into PrismContrib. My rationale is that if customers like Caliburn, let them continue to work with it. At the same time bringing over some of the cool stuff you've been doing with Actionmessages would be awesome. At the same time, I can understand why you might not want to do this and we support which ever way you (and the community) chooses. Either way we're happy have you join Prism Contrib :)
David Hayden wrote re: Prism and Caliburn's Future
on 06-12-2008 11:29 AM


P&P provides great solutions, but we all know they are not the quickest at coming out with new versions and bug fixes on their projects. They also tend to lock into their own products for infrastructure. Caliburn can be much more responsive and be a bit more technology neutral. I also see the value of having an alternative to Prism to help people better understand the technology and different implementations.

I would love to see you incorporate the best of Prism in Caliburn and get the community to help with documentation, screencasts, and samples as well as start your own Contrib Project :)

.NET & Funky Fresh wrote What's Up With Caliburn?
on 06-24-2008 1:19 PM

After asking some questions of the community and doing some thinking, I&#39;ve finally devised a plan

John &quot;Z-Bo&quot; Zabroski wrote re: Prism and Caliburn's Future
on 07-21-2008 10:37 AM
Do you think you could write a blog post comparing Prism's EventAggregator and Caliburn's two similar implementations, and what you learned from that? I like just copying (using Caliburn or Prism), but I prefer to grow.
pawan wrote re: Prism and Caliburn's Future
on 08-02-2008 7:18 AM
Between 4 and 5 !!!

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)