33

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?

Improve this question
8
  • 1
    Personally I pick and choose items out of each framework to use for specific behaviors, and I ignore the rest. For example, I like using Microsoft PRISM's EventAggregator for messaging, and NotificationObject for a ViewModelBase, and MVVM Light's RelayCommand for commands. The important thing is to identify what problems the framework is going to solve for you, and only use those solutions. Don't feel like you're forced to use the entire framework library.
    – Rachel
    Jun 19, 2015 at 20:08
  • @Rachel I was planning to use this approach with Caliburn.Micro, but couldn't find a RelayCommand implementation (since it "binds" directly to methods by convention, instead of binding to ICommand properties).
    – heltonbiker
    Jun 19, 2015 at 20:21
  • I've never used the Caliburn framework because I didn't like how closely it seemed to tie the Views to the Model/ViewModel layer. In your case, I don't see any reason why you couldn't use a RelayCommand from another library if the one used by Caliburn Micro does not work for you.
    – Rachel
    Jun 19, 2015 at 20:25
  • @Rachel regarding "how close [caliburn] ties the view to the MVM layer", what exactely do you mean? What would be the "non-caliburn" way of tying those layers in a better, more MVVM way? (I ask sincerely because I don't currently know).
    – heltonbiker
    Jun 19, 2015 at 20:59
  • Honestly I've never used Caliburn Micro, so I feel I am a bad judge of the framework. I recall getting the impression that the View was created first and was responsible for deciding the code-behind objects, which is one aspect I did not like as I don't like View-First development. Another was the automagical bindings that relied on how you Name XAML components, as I thought it tied the UI to the business layer too much. I have heard good things about the framework though, and would not suggest avoiding it just on my opinion. Try it out for yourself and see if you like it :)
    – Rachel
    Jun 19, 2015 at 21:07

4 Answers 4

Reset to default
19

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.

Improve this answer
3
  • Do you think, then, that I should at least try to use MVVMLight as some sorte of "cure" from "Caliburn.Micro disorientation"? I would surely take a look if that is the case.
    – heltonbiker
    Jun 20, 2015 at 14:54
  • @heltonbiker Definitely, give it a go. It is so much simpler should at least give you a good foothold on MVVM Framework.
    – kirie
    Jun 21, 2015 at 2:56
  • I agree there is way too much magic going on. Coming from a c and assembly background I assume. E something won't work only to find it does due to magic in the background. Impossible to debug and when you have performance issues often not much you can easily do about it.
    – rollsch
    Nov 19, 2016 at 8:45
10

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.

Improve this answer
5
  • 2
    Added to that, MVVM as offered by Microsoft (out of the box, WPF) is lacking very much. Very frustrating even for programmers who think of themselves (and rightly so) as seasoned developers. Magic strings, obscure exceptions in runtime, most basic stuff such as binding a group of radiobuttons to an enum looks like stackoverflow.com/q/397556/168719 - what can frameworks do? They have to either echo this level of complexity, or try to provide a really thick abstraction over it
    – Konrad Morawski
    Jun 19, 2015 at 19:48
  • 2
    @KonradMorawski WPF by itself is not MVVM; you can do code behind with WPF, but that's not MVVM. So if you want to do WPF and MVVM, you'll need to use an MVVM framework or implement one yourself.
    – Andy
    Jun 19, 2015 at 19:49
  • 1
    @Andy of course, but it's safe to say that WPF is intended for MMVM. I'm referring to MVVM functionality that comes built-in with WPF. I know you can still do code behind
    – Konrad Morawski
    Jun 19, 2015 at 19:51
  • @KonradMorawski You can use WPF with MVVM, and they built it with that possibility in mind in believe, but there is NO MVVM specific functionality built into WPF. Just like you can use MVP with WinForms, but WinForms offers nothing specifically to use that pattern, its up to you.
    – Andy
    Jun 19, 2015 at 19:53
  • 4
    @Andy maybe we're arguing over definitions now. What I mean is that all the "glue" which makes MVVM possible is already there - data bindings in XAML, DataContext etc.
    – Konrad Morawski
    Jun 19, 2015 at 20:03
8

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.

Improve this answer
1
  • 3
    Thanks for your answer. Two years later, I found much easier to "accept" these frameworks after understanding the concept of Dependency Injection Containers, which I learned from the excellent Mark Seeman's "DI in .NET" book.
    – heltonbiker
    Sep 26, 2017 at 4:15
2

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.

Improve this answer
1
  • You are incorrect about Cailiburn.Micro. It supports ViewModel-First and View-First with ViewModel-First being the default.
    – DaveCleland
    Jun 8, 2022 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.