Is using this MVPVM pattern with Caliburn possible?

Topics: UI Architecture
Feb 5, 2013 at 10:14 PM
I'm fairly new to desktop GUI development and have been trying to learn the concepts, benefits, and gotchas of one method over another. As I looked into MVVM, one of the complaints I saw people talking about is that you can't always eliminate the view's code behind and sometimes the VM needs to know about the view. Displaying a dialog box seemed to be one of the issues I read about.

After more reading, I saw a reference to the MVPVM pattern which seems to eliminate the view's code behind by having the presenter handle initiating things like dialog boxes while leaving the view model only handling state and totally ignorant of the view. The only thing tightly coupled and not reusable is the presenter then. This idea appeals to me and I was pleased to see that Caliburn has screens and conductors which sounded exactly what I wanted. But it seems that the conductor is still expected to be a view model that acts in a supervising controller capacity and gets auto bound to a view.

So, long story short, is it possible to use the MVPVM pattern with Caliburn? If so, would it require a lot of customization to make it work? And lastly, what might be some pros & cons of using one or the other pattern that I'm not seeing due to my inexperience?
Feb 7, 2013 at 12:24 AM
Edited Feb 7, 2013 at 12:30 AM
don't get confused with the alphabet soup that you see around the web and with various names for MVVM. MVP = MVVM they are almost completely synonymous with each other. To answer your underlying question, yes caliburn.micro can do MVVM, presentation layer is part of the architecture. You can do dialogs with CM, very easy to accomplish, many examples as well.

I came over from PRISM after realizing how horrible the WP7 offering were from the MS Research Team, not to mention a lot of the code that was required to wire a single view (region). CM does a lot of the heavy lifting that isn't necessary to recreate the wheel or write your own handlers for ICommands. This is all done under the hood with just regular void methods in your viewmodel. Composition is really easy, I use it extensively in my Desktop app as well as my Phone apps...

Also note, that unless otherwise configured for it, most out of the box CM applications don't use View first programming they do it via ViewModel first. Caliburn Micro can do both. Just a different mindset has to be used and some Dependency Properties have to be set on the Views to employ View First

Almost everything with CM without having to do any "codebehind" work, but don't get me wrong there are times when "view behavioral" codebehind is necessary or slightly easier without viewmodel intervention.
Apr 7 at 1:45 PM
"MVP = MVVM they are almost completely synonymous with each other"

Actually, that statement could confuse the development community, I'd like to share some info....

The PresentationModel and MVVM are synonymous - John Gossman, founding father of MVVM, explains this in his “PresentationModel and WPF” blog entry at Like Martin Fowler, he was careful not to overload terms. This effectively gives us a clear understanding of what MVVM is; it’s a “WPF-specific version of the PresentationModel pattern.”

The "Presentation model" exhibited exactly the problems that mugen_kanosei is discussing. Martin Fowler states the following on the topic:

"Directly updating the widgets like this is not part of Presentation Model, which is why the visual works application model isn't truly a Presentation Model. This need to manipulate the widgets directly was seen by many as a bit of dirty work-around and helped develop the Model-View-Presenter approach."

So MVP is the evolution of Presentation Model (aka MVVM).


Best regards - Bill