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?
Best Answer
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.