Reference Implementation?

Feb 10, 2011 at 3:24 AM

I apologize if this has been discussed before. I did search through the threads and didn't find anything very close.

I'm fairly new to MVVM in general, and very new to Caliburn.Micro, but not .NET programming, which I've been doing since 1.0. I'm impressed with what I see so far.

One of the pitfalls in attempting to move to WPF is that though it is not that hard to learn, it's extremely BIG. It's a daunting paradigm shift in the first place, and then the realization sets in that you can immerse yourself in one small part of it, such as Styling, only to look away from your computer screen, bleary-eyed, two weeks later. Then you notice your boss standing behind you tapping his foot. :)

My biggest problem is simply the overall "flow" of a real LOB application built on WPF. I really want to move away from the typical menu-at-the-top, tabbed-interface MDI to more of an inductive UI. I want to use VMs to mediate between the View and my business object. Etc.

But conceptually, there must still be certain abilities:

  • Lists of records of a specific type that can be queried or filtered.
  • The ability to select and open a specific record to be fully populated either for view or edit.
  • The ability to associate root records with other root records (M:M, e.g. adding one or more Image root records to a Product and creating an association record).
  • The ability to show pick lists of root records from the editing screen of another record (1:M, e.g. setting the Customer on a Sale).
  • A navigation framework for more complex records that require multiple edit screens.

I have looked at the sample projects, and gleaned some ideas. Thanks for those. If anyone can point me to a fully-functioning database-backed reference application using WPF, Caliburn, POCOs as the models, and some kind of ORM tool, I would love to see it.

I realize this is outside the scope of Caliburn per se. I guess I'm speaking from the viewpoint of someone who would really like to see this framework adopted, but as a relative n00b to WPF, I want to do it "right". WPF puts zero constraints on the design process. This is a good thing, but it also means there are far more bad ways to design something than good ways.


Thanks in advance, and thanks for all your hard work on this.

--Bruce P.

Feb 10, 2011 at 11:33 AM
Edited Feb 10, 2011 at 11:42 AM

Hi Bruce,

A full reference implementation is perhaps asking a bit much.  That being said here is an approach that I've adopted for developing View Models.

Taking the HelloScreens hybrid example from the documentation as the basis, I am very keen that the a ViewModel is just that, a Model of the View.

So, expanding on the example in the HelloScreens of the Customer Workspace. I have encapsulated required actions, and the strategy to call them outside of the ViewModel.

To specify that a VM requires a customer list I have

public interface IRequireCustomerList
  IResult GetCustomerList();


The Strategy (perhaps a better name is required here, not sure if it's technically a Strategy pattern) for actually invoking the getting of the customer list is defined as follows:


public interface ICustomerOperations
  IResult GetCustomerList(Action<IEnumerable<Customer>> callback);


This specifies a callback, the reason for which becomes obvious in the VM implementation:


public class CustomersWorkspaceViewModel : DocumentWorkspace<CustomerViewModel>,
    // customerOperations object
  ICustomerOperations customerOperations;
  public BindableCollection<Customer> CustomerList {get set [with notify of property cange etc]};  

[ImportingConstructor] public CustomersWorkspaceViewModel(Func<CustomerViewModel> customerVMFactory, ICustomerOperations customerOperations)
{ this.customerOperations = customerOperations createCustomerViewModel = customerVMFactory; } public IResult GetCustomerList() { customerOperations.GetCustomerList((resultList) => { CustomerList = new BindableCollection<Customer>(resultList); }); } public IEnumerable<IResult> InitaliseData() { yeild return GetCustomerList(); } protected override OnActivate() { SequentialResult initData = new SequentialResult(GetCustomerList().AsEnumerator()); initData.Execute(... context ...); } }


Encapsulate the actual fetching of the customer list in an IResult implementation.

In the concrete "Strategy" have something along the lines of:

public class CustomerOperations : ICustomerOperations
  public IResult GetCustomerList(Action<IEnumerable<Customer>> callback)
    CustomerResult result = new CustomerResult()
    result.Completed += (s, e) { callback(result.CustomerList); }
    return result;


To my mind, there are a few advantages to this:

Any business logic that doesn't belong in the VM has been taken out

  • The VM's responsibilities are well defined.
  • The access to the data it requires is also well defined.
  • This approach evolved from Rob's custom shut down strategy in the HelloScreens example.
  • The WPF side is not a factor in the business logic, it's purely presentational, it's databinding is only worried about the VM.
  • A lot of code could be reused in a Silverlight app.
  • Customer is just a POCO, that can be injected into the CustomerViewModel
  • Using the DocumentWorkSpace stuff for 1:M editing is already taken care of.

How the customer list is retrieved is out of scope, but could be done via a WCF service, ADO or and ORM or file based, the VM doesn't and shouldn't care.

I'd be interested to see if anyone has a different approach or if I'm just over-egging the pudding.

Feb 10, 2011 at 12:49 PM

Have a look at

Feb 10, 2011 at 1:08 PM

Also, it's definitely worth looking at the contest winner's apps:

Feb 10, 2011 at 3:15 PM


Excellent. Thanks for the tutorial and the detailed explanation. The naming conventions really help to understand these concepts and the separation of concerns. To someone like me, who initially thought three tiers was a bit much, this whole thing looks like "over-egging the pudding". =c) But I'm starting to see the benefits that accrue from this approach.


CoProject looks ideal as something to dig into. Thanks.

--Bruce P.

Feb 12, 2011 at 6:25 AM

Worked through Coproject, and though it's Silverlight rather than WPF, it was a tremendous help. I now have a much deeper understanding of (and appreciation for) "convention over configuration". =c)

Thanks again.

Feb 12, 2011 at 8:28 AM

You might also check It's a reference application I'm working on demonstrating several techniques for building a line-of-business application. Obviously it uses Caliburn Micro, but also shows some architectural patterns that I've been blogging about at