Implementing MVC with Windows Forms

I am of the view that applications are so different from each other and our understanding of how applications should be written is still very limited. Past Windows Forms applications I have worked on have been so different from each other. Some of the design differences I have seen are (including most combinations):

• Directly talk to the database (2 tier)
• Use a backend that has been written for the given application (3 tier)
• Use a set of web services that were written for use by many applications and can’t be changed for your application. (Service-oriented architecture)
• Updates being done by CRUD operations
• Updates being done with the command pattern (sending commands to backend server)
• Lots of usages of data binding / no usages of data binding
• Most data being “table like” (e.g. invoices) that work well in standard grid controls / need custom controls for most of the UI data.
• One developer / teams of 10 or 20 developers (just on the UI)
• Lots of unit test using mocks etc / no unit tests

Therefore I don’t think it’s possible to create one implementation of MVC (or MVP) that always fits well.

The best posts I have seen really explaining MVC and why an MVC system is built the way it is, is the "Build Your Own CAB" series by Jeremy D Miller. After working though it you should be able to understand your options a lot better. Microsoft's Smart Client Guidance (CAB / Microsoft Composite Application Block) should also be considered. It is a bit complex, but it can work well for applications that have a good fit.

Selecting an MVC/MVP Implementation for a Winforms Project give an overview that is worth reading. A lot of people like PureMVC. I have never used it, but I would look at it the next time I need a MVC framework.

"Presenter First" is a software development approach that combines the ideas of the Model View Presenter (MVP) design pattern and test-driven development. It lets you start off by writing tests in the customer’s language. For example:

"When I click the 'save' button then the file should be saved and the unsaved file warning should disappear.”

I have no experience using "Presenter First," but I will give it a try when I get a chance, as it looks very promising.

Other Stack Overflow questions you may may wish to look at are here and here.

If you are thinking of using WPF at any point take a look at the Model-View ViewModel (MVVM) pattern. Here is a very good video you should take a look at: Jason Dolinger on Model-View-ViewModel.

MVVM (Model View View Model) Design Pattern for Winforms give another option that may make it easer to convert to WPF if ever needed. Magical.Trevor is yet another MVVM sample for Windows Forms that also includes auto binding based on property names.

---

Also ask yourself why you are using MVC.

• Do you wish to be able to unit test as much code as possible?
• Are you trying to allow as much code as possible to be reused?
• Are you trying to make your code base easy to understand?
• 101 other reasons that can be valid for a given project.

Once you are clear on your aims, it becomes easier to choose one implementation or another.

Have you looked at PureMVC? I've found that no one can agree on what MVC really looks like once they start building a specific implementation.

Update: You could build your own starting with something simpler such as MobileMVC. Compact Framework code should compile/run OK on Windows. Since this is a school assignment I would suggest that you actually spend some time learning how MVC actually works.

UPDATE: In addition to my previous answer below, I suggest reading about the "Presenter First" approach (especially the PDF articles)

I would recommend MVP (PassiveView pattern actually) instead of MVC. You don't really need any special frameworks for this, it's just how you organize your code.

One approach (which I usually take) is to split each windows form into three entities:

1. A presenter/controller class - this is what you actually start with when developing a form. This is where most/all of your "business" logic should reside.
2. A view interface (IView), which contains the methods, properties and events. This interface is all that the presenter knows about your form.
3. At the end, when you finish implementing the presenter and the view (including unit tests), you can then create the actual form class and make it implement the IView interface. Then it's just a question of adding appropriate controls to the form and wiring them to the interface.

Example code (a simple pseudocode, just for illustration):

interface IView
{
    string Username { get; set; }
    string Password { get; set; }

    event EventHandler LogOnButtonClicked;

    void InformUserLogOnFailed();
    void MoveToMainScreen();
}

class Presenter
{
    public Presenter(IView view)
    {
        this.view = view;
        view.LogOnButtonClicked += new EventHandler(OnLogOnButton);
    }

    private void OnLogOnButton()
    {
        // we ask some service to verify the username/password
        bool isLogOnOk = logOnService.IsUserAndPasswordOk(view.Username, view.Password);
        if (isLogOnOk)
            view.MoveToMainScreen();
        else
        {
            view.Username = "";
            view.Password = "";
            view.InformUserLogOnFailed();
        }
    }

    private IView view;
}

class Form : IView
{
    public Form()
    {
        presenter = new Presenter(this);
    }

    public string Username
    {
        get { return TextBoxUsername.Text; }
        set { TextBoxUsername.Text = value; }
    }

    public string Password
    {
        get { return TextBoxPassword.Text; }
        set { TextBoxPassword.Text = value; }
    }

    public void InformUserLogOnFailed()
    {
        MessageBox.Show("Invalid username or password.");
    }

    public void MoveToMainScreen()
    {
        // code for opening another form...
    }

    private Presenter presenter;
}