Monday, March 07, 2011

Introducing the Silverlight Cookbook

In the 2nd half of 2010 I was so fortunate to get the chance to build my first enterprise-class line-of-business application written in Silverlight 4. And although I designed my original reference architecture earlier that year, actually building it is a completely different thing. I learned a lot from that, and also managed to try a few different alternate styles, and I’m quite confident my current architecture should work for a majority of the cases.

And that’s exactly why I wrote a series of posts last year and which I’ll continue soon. And that is also the reason why I started the Silverlight Cookbook a month ago. The Silverlight Cookbook is a Codeplex site hosting a Silverlight 4 application that includes most of the complexities you might run into when building a line-of-business application. It’s a spin-off of my previous community effort, The CQRS Kitchen, which was an attempt to demonstrate how to build a system using the Command Query Responsibility Segregation and Event Sourcing concepts. But because systems that need those aspects are rare, I decided to move my attention to more traditional systems. Nevertheless, the commanding pattern from CQRS has found it’s way into the cookbook as well.

The Cookbook uses NHibernate 3 in its persistency layer and you may wonder why I’m not using Entity Framework 4 yet. About a year ago I did a small talk on comparing NH 2.1 to EF 4 CTP 3. At that time my conclusion was that although EF was mature enough, NH’s mapping flexibility was much more powerful when you need to work with legacy databases, even though its LINQ implementation was lacking a lot. The major USP for EF was its design-time support, but since in most of my projects I’ll hand-code the domain entities anyway, that’s not something I value much. It’s major flaw (and it still is), is its lack of a 2nd level cache. Today we have NHibernate 3.1.0 with a very complete built-in LINQ implementation and we have Entity Framework 4.1 RC with fluent mapping and supporting some level of convention-based programming. Still, IMHO that is no match for the power of NH 3.1.0 and Fluent NHibernate. That we still don’t get a 2nd level cache is something I (and quite some members of the community) really don’t understand.

Because of the separation between the commanding side, which is based on a traditional WCF service, and the querying side, the Cookbook uses WCF Data Services for exposing the domain model over a REST interface. And I know that the combination of NHibernate and WCF Data Service is not a happy marriage yet, it works reasonably well, especially since version 3 provides much better support for LINQ. In contrast to the glue Shawn Wildermuth added in the now deprecated NHibernate.LINQ, NH 3 does not provide anything to hook NH into WCF Data Services. But I managed to take his stuff and get it to work with NHibernate 3 in the Cookbook.

In terms of automated testing, I’ve switched from Rhino Mocks to FakeItEasy. Why? Because Rhino Mocks still doesn’t officially support Silverlight (there’s just an alpha version), and it seems Ayende has lost interest in the plans for Rhino Mocks 4. The most recent version, 3.6, dates September 2009. I did consider moving to MOQ, but I don’t like its intermediate Object property. As far as I can tell now, Patrik Hagne, the author of FakeItEasy, has managed to combine the best of MOQ and Rhino Mocks and officially supports Silverlight as well. I’ve moved all the unit tests of Fluent Assertions, my unit test assertion framework to FakeItEasy as well, and am currently using it in a big client project.

The backbone of the Silverlight Cookbook is provided by Caliburn Micro. I’ve already blogged, talked and tweeted a lot about this beautiful framework, so I won’t repeat how it solves many of the complexities of building Silverlight applications (asynchronity, binding expressions, MVVM). What I do want to mention is that Microsoft’s Patterns & Practices team should seriously consider talking more to Rob Eisenberg, the author of both Caliburn and Caliburn Micro. I wish we knew about it when we started with a WPF project last year.

So what about the near future? Well, I’m still checking in changes to the application on a regular basis, and refactoring many parts of it. I see the Cookbook as an ongoing effort to demonstrate and prove new ideas for problems I run into in my daily job. Some of the things I have in mind for the near future include:

  • Dynamic loading of modules
  • Deployment-friendly handling of configuration settings
  • Event Aggregation
  • Using Reactive Extensions as an alternative to coroutines.

As a matter of fact, I’m still looking for people to help me continue improving the Silverlight Cookbook, both on the development side as well as on improving it’s user interface design. So if you’re interested let me know or use the Join Us page on the site..

This article is part of a series of posts dealing with all the choices and solutions used in the Silverlight Cookbook. If you have any comments, let me know by commenting or sending me a tweet on @ddoomen.