Ok, I know this sounds like an odd question but I'm wondering if anybody has tried to use the MVVM pattern with Winforms?
The reason I'm pondering this is as a means of providing a migration path for very large Winform applications whereby we create modelviews and views for parts we can afford to migrate to wpf/sl but also perhaps slip the MVs in between our winform UIs and business objects as a means of getting nearly there over time.
Obviously I haven't thought deeply about this so this question is just a tester for opinion really.
In truth I would say 50/60% of our Winform UIs are single liners just calling a factory method on business objects(collections) so migration should be simple. The rest of the UI code is simple designer settings although these forms do rely on inheritance to encapsulate all the commonality of dealing with errors, saving, binding, etc.
This leads me to another question – for such simple bind/save UI do you think the MVVM pattern adds value? I have to admit that for a long time I simply didn't get what MVVM was all about. All I could see no matter who explained it to me was extra (duplicated) code and complexity for, what seemed to me, very little testability benefit. Even then most of the code I was shown blurred the boundaries so much that I couldn't even see how testability was improved (or even possible in some cases). I came to believe this was just herd mentality at its worst - everybody believed this was the way to do things but nobody could give me a convincing argument as to why. Then I saw Rocky all over it and I seriously thought I’m finally past it – my programming lifespan has been all used up. Finally, I found a post where Rocky mentions the anaemic and rich model versions and my sanity was restored.
Concerning the first part: I can't exactly remember the binding options you have in winforms. But as far as I remember, this has been quite a challange.
Concerning the second part:
The post you mentioned about the rich model nature of CSLA BOs is really important. I think the benefit of having a ViewModel shows up more sonner than expected: it's having a clear design! You start with one Property (your Target) and have a load and save mechanism. For your 50/60% simple UIs you to can provide a (generic) base ViewModel. And for these UIs this might be sufficent.
But user demand for entering support (auto completion, selection from availables). Having a ViewModel you clearly know, where to add this functionality (hmm, actually you sometimes still have the choice of ViewModel or a calculating CSLA BusinessRule...)
Stefan
In concept it is possible. In practice, it depends on whether you can make two things work smoothly:
I haven't done Windows Forms in so long that I don't know how hard #1 will be. I suspect it can be done, but I'm not sure about the work involved.
I know there's no such thing as event binding in Windows Forms, so #2 must be invented. Then again, there's not a great story for event binding in XAML either, and that's why CSLA has the TriggerAction control.
It might be possible to create something similar to TriggerAction for Windows Forms. But it might be easier to do the "poor man's event binding", which is to use the event handler in the code-behind like normal, but in that event handler have exactly one line of code that invokes the appropriate method on the viewmodel. Simple delegation, and this works fine.
As always thanks for taking the time out to reply. The idea is fuzzy in my head but as/if I advance I will put some things to the test and see if there is any merit in trying an mvvm approach in winforms.
I was thinking on a very simplistic level though in that I would leave the existing winform ui's pretty much intact changing only the binding from direct to the business layer instead to the vm layer (created for upgrade to wpf/sl) and rewiring any method calls. Code-behind where it currently exists would remain.
I know this really wouldn't give any benefits to the winform app but might allow us to ensure continuing work on those would move us closer to a cheaper migration to wpf/sl. Our major difficulty, as I suspect with many folks out there, is very heavy investment in winform technology in the early 2000's. The money's all spent now but the products are still evolving and we are faced with a dilemma of trying to advance the technology yet have it live within the framework of existing systems.
Some years ago in a winforms project we had to provide a "plug-in" UI for serveral applications. Of course MVVM was not known then, nevertheless we took a similar approach (inspired from MVP). The view model (we called it presenter) coordinated the widgets on a UI and the model.
We took the same approach as you're planning (although we put some interfaces between, but this has only been reasonable due to the plugin requirement).
I was thinking on a very simplistic level though in that I would leave the existing winform ui's pretty much intact changing only the binding from direct to the business layer instead to the vm layer (created for upgrade to wpf/sl) and rewiring any method calls. Code-behind where it currently exists would remain.
I definitely want to encourage to introduce a view model "layer" as you planned. The design benefits while the extra work is small.
It happens I'm on this subject.
I'm doing a VisualWebGUI project. VWG is a WindowsForms like environemnt and reproduces System.Windows.Forms namespace as Gizmox.WebGUI.Forms. This means it has the same controls with the same behaviour (well... almost the same). It was easy to port Csla.Windoes to Csla.WebGUI.
VisualWebGUI compiles to web pages and is much easier to work with than ASP.NET with or without AJAX. I'm writing the draft code in WindowsForms and then, form by form, port it to VWG.
I became used to MVVM and miss it. So I looked around and found three interesting things:
My next move is try to port Caliburn.Micro to WindowsForms. After it's done, I'll try to port Csla.Xaml to WinForms and WebGUI. By the end of the day we'll have a MVVM environment for WindowsForms and Web applications.
At http://mvvmfx.codeplex.com/ you will find some useful MVVM stuff for Windows Forms:
1) a databinding library with converters that can also bind an Action to a property change
2) a command binding library that can bind an Action to any input event of any UI component
<edit>
I'm coordinating this project.
</edit>
Copyright (c) Marimer LLC