Can you point me to a good real-world WinForms MVC application/framework?
I understand the Model part - that's your data, and I know the forms are the views, but what's the controller? Especially if I want to use data binding.
Can you point me to a good real-world WinForms MVC application/framework?
I understand the Model part - that's your data, and I know the forms are the views, but what's the controller? Especially if I want to use data binding.
Check out StoryTeller source code.
It's a work in progress, but should give you plenty of ideas/sample uses:
And yes, I am still actively developing it, it just got shelved for other projects. I'm using it for acceptance testing in my new job and I'll release after the (many, many) kinks and annoyances are ironed out. Ah, the joys of dogfooding.
I believe Jeremy is writing a book on WinForms development as well.
Check out http://www.asp.net/mvc/ - there are some links to webcasts that Scott Hanselman has been doing.
He also has some interesting stuff regularly on his blog and podcast - see http://www.hanselman.com
Before using MVC make very sure you know why your are putting yourself thought the pain. Having sections of code split into logical groups is great, moving logic out of the UI is great, but going the full nine yards can be more effort that it is worth. (imho)
Adding data binding to the mix will cause you to end up hybrid in most cases. In the project that I am currently working on we reached the same position as you and after much talk and research ended up with the following.
Model
This would be your data as you said, in our case it is our Domain objects that contain information on the domain. eg. Person, Company ...
These domain object are data bound to the forms, in this way providing direct communication between your MODEL and your VIEW.
View
This would be your user interface or windows form. Now since you are using data binding you will most probably have a BindingSource on your form with its Datasource pointing to your domain object. Having the View being directly connected to the Model already start to break MVC. Take a look at the wikipedia article on MVC and its related diagram on the accepted communication. But as I said earlier, we are going to end up with a hybid anyway...
Controller
The controller will end up not doing anything close to what a real controller is meant to do. In the ideal MVC world, the controller will handle all interactions with the view. click a button: the controller works out what to do and updates the view after doing it. select an item in a combo box: the controller works out what to do and updates the view after doing it. and so on...
For this "implementation" the controller will be charged with providing all the nasty code that we dont want cluttering our UI .cs file. So if dropping down a combo box needs to populate another related combo box, put this code in the controller. If a form needs to conduct a complicated save routine to put together three object and save them in the right order, put this code into the controller.
What does this mean in implementation terms
When you create a new instance of a form you need to do two things.
But this question is best served with an example, so check out the example solution that I threw together. I have chosen to communicate between the Form (VIEW) and CONTROLLER with direct calls, but you could always make use of events (which i think is the more accepted norm).
Hope it helps..
Shouldn't an MVP (instead of MVC) architecture suit better a WinForms application?
It's not a real-world sample, but Martin Fowler has some good articles on GUI Architectures where he discusses MVC and MVP. In fact he's coined the term Supervising Controller when using a MVC pattern with a UI framework that supports data binding.
Craig Shoemaker made couple of good screencasts and podcasts about this on his show.
I've got a few posts up (and some sample code) for a simple Model-View-Presenter with Windows Forms and data binding on my blog here: http://garoyeri.blogspot.com. Look for the posts tagged "stocksample". Usually I mix Model-View-Presenter with a Controller to actually perform actions and load the presenters.
Have you checked out the MVP (Model/View/Presenter) format of the Smart Client Software Factory (SCSF), part of Microsoft's Patterns and Practices?
See www.codeplex.com/smartclient.
It is a big committment, with a learning curve, I'd recommend you at least read David Platt's book to get a good basic understanding of it (www.rollthunder.com/Books/CABandSCSF/index.htm). It generates a lot of code for you (the code is pretty good, but since you didn't write it, it can be daunting until you understand it better). We used it successfully to create a client application where two separate but integrated UI compomponents were created by different vendors, fairly independently, and the framework made them coexist very nicely.
I am also new to MVC/MVP patterns on Windows Forms, so I've been doing some research recently. Apparently, the pattern used in Windows Forms is actually MVP, a derivative of MVC, because of the way the controls/widgets handle the UI events themselves, not the controllers (even if only to delegate to the Controller/Presenter). MVP itself can be subdivided into Supervising Controller and Passive View patterns.
I found the following MVP frameworks for WinForms:
Microsoft patterns & pratices: Smart Client Software Factory (SCSF) relies on the Enterprise Library (EntLib) and the Composite Application Block (CAB). It's very big and generates a lot of (apparently good) code for you. Requires installation of Guidance Automation Extensions (GAX) and Guidance Automation Toolkit (GAT) VS add-ins to create a wizard-like experience and context-sensitive menus ("add view", "add controller", etc). Doesn't support EntLib 4.1 or VS2008SP1 without some fixes. For my very small project, this was bloated overkill.
Microsoft patterns & practices: Composite Application Guidance for WPF (aka Prism or Composite Application Library, CAL) is newer than SCSF and a lot simpler. p&p seems to have listened to developers by removing the requirements for EntLib, GAX, etc. Its only dependency is Unity as the default DI container (you can use others). Implements other related patterns such as Commands and Event Aggregation for further decoupling. They tried to keep the WPF-specific stuff separate, so WinForms support can be added. Prism 2.0 was released Feb 2009 and adds Silverlight support.
MVC#: MVP framework which supports WinForms, WebForms, Silverlight, and the Compact Framework (Oleg Zhukov). It is simpler than p&p's offerings and has no external dependencies. Does not use a separate DI container nor does it implement event aggregation, etc. I didn't like the way MVC# tries to be very declarative by default. It relies so much on attributes that you need to declare "magic strings" as fields just to hang the attributes on. Then again, it also supports XML file configuration instead of attributes and you can write your own config providers. Generics support (IController<IView>) seems to have been added only recently.
Source code is available for those frameworks. I also found some samples and walk-thoughs that can get you started if you want to roll your own:
Further reading (you'll find lots of cross-linking between these):
I haven't decided yet if I will use Prism (with Winforms extensions), MVC# (and write my own providers, say no to magic strings), or end up writing my own very very simple MVP "framework". Or I could switch to WPF and use Prism as-is.
EDIT: Composite Application Guidance for WPF and Silverlight (Feb 2009)(aka Prism v2) has been released.
Please visit my blog -
http://www.cerquit.com/blogs/post/MVP-Part-I-e28093-Building-it-from-Scratch.aspx
These include sample solution.