What were the design goals of SoapBox Core?

Design Goals of SoapBox Core

I started writing another application (eventually to be released as GPL - for very good reasons that were discussed with a lawyer) and I had these requirements:

1. It had to be extensible, so anybody could extend the functionality with Add-Ins without necessarily having to co-ordinate with me.
2. It had to be WPF using the Model-View-ViewModel pattern.
3. Everything I used had to be GPL compatible.

SoapBox Core is just my attempt to accomplish these goals. Now I understand that you can accomplish goals 1 and 2 with Composite WPF (aka PRISM) or the WPF Application Framework. Unfortunately they're licensed under the Ms-PL so I wouldn't have been able to use them in a GPL'd application. It turns out that MEF (which SoapBox Core uses for extensibility) is also licensed under the Ms-PL but it will eventually be included with .NET 4.0, and at that point it becomes a system library and the GPL doesn't care about it.

Once I started writing SoapBox Snap, I realized that a lot of the stuff I had written was probably applicable to writing other applications, so we decided to break off the generic stuff as a separate library called SoapBox Core and release it under the LGPL license so anyone can use it, even in proprietary applications. That is the (very short) story of SoapBox Core. It is what it is. I also hope that it will be an interesting reference application for people interested in how to follow the Model-View-ViewModel pattern in their applications.

SoapBox Core Philosophies

For better or for worse, these are the ideas that were floating around my head as I wrote SoapBox Core:

1. Everything is an Add-In: Just like SharpDevelop, which influenced my thinking heavily, every significant feature should be implemented as an Add-In to SoapBox Core, and Add-Ins can extend other Add-Ins.

2. Pragmatic Views: I am not a "Code-Behind Zealot". As far as I'm concerned, the Code-Behind is part of the View. As long as you only put View-related logic in there, it's still perfectly legitimate Model-View-ViewModel. I don't use them too much, but I also consider Value Converters to be part of the View as well.

3. (Almost) Every Class is a ViewModel: In SoapBox Core, everything that implements IViewModel is a ViewModel, so I don't use the ViewModel suffix on my ViewModel classes. It just gets too verbose. In fact, almost every class in SoapBox Core that isn't imported from another library (like NLog, AvalonDock or Physics2D) is a ViewModel.