MVVM is most commonly used with WPF because it is perfectly suited for it. But what about Windows Forms? Is there an established and commonly used approach / design pattern like this for Windows Forms too? One that works explicitly well with Windows Forms? Is there a book or an article that describes this well? Maybe MVP or MVC based?
I have tried MVP and it seems to work great with windows forms too. This book has an example of windows forms with MVP pattern (sample payroll application). The application is not that complex but will give you an idea about how to go about creating it.
Agile Principles, Patterns, and Practices in C#...
You can get the source code at Source Code
EDIT:
There are two variations of the MVP pattern (a) Passive view and supervising controller
For complex databinding scenarios I prefer to go with the Supervising controller pattern. In supervising controller pattern the databinding responsibility rest with the view. So,for treeview/datagrid this should be in the respective views, only view agnostic logic should moved on to the presenter.
I'll recommend having a look at the following MVP framework MVC# - An MVP framework
Don't go by the name (it's an MVP framework).
Simple winforms MVP video Winforms - MVP
An example of dealing with dropdown list MVP - DropDownList
Simple treeview binding example (poor man's binding)... You an add any treeview specific logic in the BindTree()....
Below is the code snippet.... not tested, directly keyed in from thought....
public interface IYourView { void BindTree(Model model); } public class YourView : System.Windows.Forms, IYourView { private Presenter presenter; public YourView() { presenter = new YourPresenter(this); } public override OnLoad() { presenter.OnLoad(); } public void BindTree(Model model) { // Binding logic goes here.... } } public class YourPresenter { private IYourView view; public YourPresenter(IYourView view) { this.view = view; } public void OnLoad() { // Get data from service.... or whatever soruce Model model = service.GetData(...); view.BindTree(model); } }
The best article I have read is from Martin Fowler's blog. Here:
Hi,
As it has already said, i always worked in a MVP pattern when using Winforms. But the design pattern you will use not mean you will use right. There is loads of anti-pattern attached to MVP.
If you want to starts everything in a good manner, you have to use the framework for building smart client. So i will recommend to use that design and practices: Smart Client Software Factory http://www.codeplex.com/smartclient
You have a discussion here about the current smart client frameworks : http://codebetter.com/blogs/glenn.block/archive/2008/05/10/prism-cab-and-winforms-futures.aspx
PS: I like this post on the MVP anti-patterns: http://blog.mattwynne.net/2007/06/13/mvp-smells/
Hope this helps
The BindTree method seems a little flawed to me. Suddenly the the View knows abou the Model. Is that a good thing? There must be tons of poeple being confronted with these kind of problems. I am surprised that there aren't any books about it. Since there are books about everything in the .NET world.
These Design not about hiding the model rather precisely defining the interactions between the different layers of the applications. You can change the backend completely and as long as you pass a Model through Bindtree your UI will continue to work.
Now class Model may be a poor choice of a name in the example that Rajesh gives. It can be TreeData, or RecordsData. However you define it, it has what you need to using the binding mechanism of Winforms to bind a specific control to the underlying data.
The best site to browse for this kind of material is here. Martin Fowler has collected a variety of useful UI design pattern and enterprise design patterns.
Again the key to this is the use of interfaces to precisely define how each layer interact with each other.
In my own application (a CAD/CAM applications used to run metal cutting machines) my structure looks like this.
- Forms implementing form interfaces
- UIDLL with views implementing view interfaces that interact with forms through the form interface. The specific views register themselves with UIViewDLL Views executes Command Objects found in command libraries that interact with the Model.
- Command libraries; lists of commands implementing ICommand. The command that interact with views do so through the interfaces exposed in UIViewDLL.
- UIViewDLL; exposes the View Interfaces used by the commands.
- Model; the classes and collection that make up core data structures of my application. For me these are things like material, cuttingpaths, shape, sheets, torches, etc.
- Utility; a DLL that has commonly used utility classes used by my company that span different application. For example complex math functions.
The first good explanation of UI design patterns I read was in Jeremy Miller's blog - Building Your Own CAB. It describes the common patterns - Passive View, MVP, etc. and addresses some of the ways you might implement them in C#.
I believe that MVP is a pattern well-suited to WinForms development (as is partly evidenced by it's prominent use in CAB - Microsoft's framework around WinForms applications).
I use MVP, in WinForms apps, primarily to extract code out of the View, as I can't/won't test the View code. And also to enable code that needs to be reused (or is duplicated) to stay out of the View where it can't easily be shared.
As some evidence of the effectivness of MVP in WinForms, I will refer to my own project. I work on the ExceptionReporter project (www.codeplex.com/ExceptionReporter) where I actually need to reuse code between a WPF and WinForms "version" of the software. Hence, I use MVP for both technologies - which allows me to share the same Presenter between both assemblies. And avoid duplicating that code.
You mentioned MVVM working for WPF - I think the reason for that is because of strong data-binding support. If you were not using data-binding in WPF (and it's certainly not compulsory) then you could choose MVP. The point being that MVP is a strong choice for any client-side application. And possibly a 'better' choice, even in WPF, if you plan on sharing code between projects that aren't WPF.
For more evidence of the value of using MVP in WinForms see Boodhoo's video presentation on using MVP: http://www.bestechvideos.com/2008/06/29/dnrtv-show-14-jean-paul-boodhoo-on-model-view-presenter And an MSDN article by the same author at http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
The following post introduces a variation of MVP design pattern called MVP-VM, which is a tailor made solution for winforms applications that require full testing coverage and use data binding as main mechanism for keeping the presentation updated with model data.
MVP-VM (Model View Presenter – View Model) Design Pattern for .NET Winforms
MVVM (Model View View Model) introduces similar approach for separating the presentation from the data in an environment that empowers data binding (WPF). Since .NET framework 2.0 already offers advanced data binding infrastructure that also allows design time binding of application objects - the ‘View Model’ entity can fit quite well in MVP based environment.
The Model-View-ViewModel (MVVM) Pattern is a design pattern. Per definition a design pattern shows a common solution in the object-oriented world and this solution can be applied in various platforms (WPF, WinForms, Java Swing, etc.). I agree that MVVM is best used with WPF because it leverages the strong binding capabilities. However, Windows Forms supports data binding as well.
The WAF Windows Forms Adapter shows how to apply the MVVM Pattern in a Windows Forms application.