How to choose NOT to use a framework (Caliburn.Micro, etc.) in a given MVVM application?

Question

I have once started a MVVM/WPF project, which was eventually built and deployed, and for that I studied a lot of the Caliburn.Micro MVVM Framework. The fact is: I ended up not using Caliburn.Micro for that, and ended up implementing some MVVM concepts myself (specifically, just the ViewModelBase and RoutedCommand classes).

Now I was assigned to a somewhat larger project along the same lines: a "Single-User Rich Client Offline Desktop Application", so to say, and I decided to use Caliburn.Micro. And that's where my "problem" begins.

I have read in this famous blog post, whose title says that "If you're using MVVM then you need a framework", that:

"Trying to do something like MVVM without a framework is a huge amount of work. Tons of duplicate code, reinventing the wheel, and retraining people to think differently.

At least with a framework you avoid the duplicate code and hopefully don’t have to reinvent the wheel – allowing you to focus on retraining people. The retraining part is generally unavoidable, but a framework provides plumbing code and structure, making the process easier."

I would agree upon first reading but my actual experience with Caliburn.Micro (CM) in my actual application is being of cluelessness and disorientation. That is, the framework didn't make the process easier at all, quite the opposite. Reading the ever-repeating examples provided by Rob Eisenberg in the rather (too) informal documentation, and trying to infer usage patterns from the convoluted provided samples, and their utterly indirect class and interface relationships, where things seem to be designed to work based on side-effects, seems humanly impossible unless you are a seasoned genius (sorry for the rant, but I guess you know what I mean).

Not to mention that any above-trivial scenario seems to involve IoC containers, which is something I have never worked with, and which seem to solve a problem I might not even have. I don't feel like spending more project hours learning those things instead of thinking about my problem and application domains. I just wanted a banana, but CM gave me a gorilla (IoC) holding a basket of bananas.

Now that I am considering to move back to my homespun MVVM framework - composed only of the handful of MVVM-specific classes I actually want to implement - I would like at least to give CM a chance, in case I am losing something here, or just plainly doing things "the wrong way" out of sheer inexperience and ignorance. And so the question is:

There are widespread consensus that "frameworks make things easier and more natural", but if I happen to be experiencing quite the opposite, does this mean that I shouldn't use the framework, or that I am trying to learn it the wrong way? Is there a clue that I shouldn't even be using a framework in the first place? Or is there some "right" way to figure out how to use CM for simple MVVM development?

Answer 1

I have tried CaliburnMicro and MVVMLight and when using Caliburn I really feel what you feel, sure it feels really magical able to bind a control to a property just by using Name="PropertyName" instead of old Text="{Bind PropertyName}" but in the end Caliburn goes way overboard to do this magical thing. When something goes wrong it is really hard to debug and to make things worse they have a lot of ways to do one thing.

In contrast, MVVMLight is really thin. When you use it you probably realize that it is almost 100% like your MVVM Framework, with some feature sprinkled in it.

I know this doesn't answer your question "How NOT to use framework" but frankly I can't recommend you go that route. I think you are just lost because you used a full featured framework instead of using a simple one first.

Answer 2

It is important to realize what MVVM is. It is not some shared bit of functionality that you do not have to reimplement (parsing a JPEG file or connecting to a given SQL database server), it is a pattern--a pattern for how one may choose to implement a rich GUI. So, if your implementation of the pattern is simple and straightforward, I do not think you need feel any shame in using it rather than a framework.

Indeed, I believe the whole patterns-as-frameworks idea has gone much too far. For anything to be a pattern it has to be the general shape of a class of solutions. Because this is so, it is to be expected that patterns will need to be tailored to the systems that use them and you cannot do that if you try to use a one-size-fits-all pattern. It would be far more constructive to leave pattern implementation to the application designer and provide libraries that encapsulate functionality, rather than architecture.

Answer 3

My first experience with WPF has been using Caliburn.Micro so this is probably quite different from most developers. I have found both WPF and Caliburn.Micro to be quite a steep learning curve, coming from WinForms, however after some experience with both I have found them a pleasure to use as a pair. Currently working in a different organization where Caliburn.Micro is not used I do find that there is A LOT of duplicate plumbing code which makes the codebase quite bloated and unnecessaserely complex.

I definitely agree that there are some gotchas with Caliburn.Micro, which can complicate debugging, however once experienced they are much less likely to be a pain again. The increased development speed, cleaner and leaner code and the overall framework encouraging better MVVM are more than worth it for me.

Caliburn.Micro also does not invalidate stock WPF - it just builds on top of it, which means that you can still use WPF features if you like and use Caliburn for a few bits and pieces if you like. This is similar to how TypeScript and JavaScript coexist together in my mind.

I would most definitely use Caliburn.Micro in any new WPF project I work on in the future if given the chance.

Answer 4

For anyone who arrives here out of frustration with Caliburn.Micro, have a look at this framework: Stylet

It's inspired by Caliburn.Micro, except it removes a lot of the magic that leaves you disoriented about what's happening. Additionally, the documentation is written in much plainer language without assuming you want to wade through technical jargon. Much better for beginners.

Also, Stylet takes a ViewModel-First approach. Caliburn.Micro and a lot of other frameworks take a View-First approach, which comes with some awkward problems. If you are already very good at SOLID principles and patterned code, you are likely to find a ViewModel-First approach more natural since it takes the perspective that your logic should drive the system -- not the view.